Re: How do I turn ANSI-terminal colourising off?

On 15/08/2013, at 8:04 PM, Jan Wielemaker wrote:
>> The big thing is that there are features that the user has to
>> *choose* and there are features that are *forced* on the user
>> and the user *must* be told at least once about the latter kind.
> 
> Is worth considering.  Not really on my shortlist though.  It
> requires infrastructure to collect these messages, some form
> of guidelines to structure them and maybe worst, a sensible
> way to display them.

Following the dbx pattern, the infrastructure is minimal.
(1) There is a file that describes the new features,
    highest impact first.
(2) There is a flag that says what was the latest version
    the user knows about, default being 0.0.0.
(3) At startup, after loading the user's .plrc,
    if the version flag is less than the current version,
       include these lines in the banner:

	For changes since <flag version>, see <file name>.
	To suppress this message, add this to ~/.plrc
	:- set_prolog_flag(new_features, <version>).

Done.
> 
> Input lines don't go through the message systems and are thus
> not coloured.

That's a non-=sequitur.  They *could* be coloured by sending the
appropriate control sequence to the terminal.  In fact, they
*are* coloured because SWI Prolog *does* send colour-setting
sequences to the terminal that *do* affect the typed colour.
> 
> These are informational messages.
> 
>> purple  true.
> 
> These are printed using print_message(query, query_result(Term)),
> which is handled in boot/messages.pl.   Some of the colouring there
> is hard-wired.  true. is printed in *bold*.

Now that some of the colouring is user-settable, it seems odd that
*any* should be hard wired.  It need not use the same mechanism for
printing, but should all use the same mechanism for colour selection.

>  If it is purple, there is something wrong.

Nope.  Terminal|Preferences|Settings|Text lets you pick
 - font and size
 - whether to use antialiasing
 - what colour to use for text
 - whether to use bold fonts
 - what colour to use for bold text
 - whether to use bright colours for bold text
 - whether to use blinking text
 - what colour to use for selection
 - whether to display ANSI colours
   [I *do* wish Apple would learn to localise...]
 - what the ANSI colours map to
 - whether the cursor is a block, underline, or vertical bar
 - whether to make the cursor blink
 - what colour the cursor is

This kind of customisability is one of the reasons why it
makes sense for a *GUI* interface to colourise but much
less sense for a *terminal* interface to try to impose its
own colours.

Looking at the setups available to pick from,
bold is black  in 3
        orange in 1
        green  in 1
        purple in 1
        red    in 1
        white  in 3
        ochre  in 1
and one of those is my own custom set up (the red one, I thought
I'd see how that looked today).

>  I'd suspect your terminal emulator.  At least,
> it works fine in at least 4 different emulators I use.  You can
> define
> 
> prolog:message(query(QueryResult)) -->
> 	...
> 
> to make it behave as you want.

That's good, but if it's not *implemented* in the same place as the
other colour settings, it needs to be *documented* in the same place.
> I don't think I have to explain how
> that works :-)
> 
>> - What is the message_property that controls the colour of the prompt?
> 
> The prompt is not printed by print_message/2, but defined by prompt/2.
> I guess you can put ANSI sequences in there.

Again, it needs to be *documented* on the same page as other colour or
style setting.

>  Not sure GNU readline's position logic likes that.

That reminds me of another issue.
If I want rlwrap, I know where to find it.
(rlwrap's --ansi-colour-aware suggests that there _is_ a
problem which _can_ be configured away; I know no details.)
Using a terminal emulator with a very long history,
I very seldom _do_ want rlwrap.
If I build SWI Prolog from sources,
I know how to stop it being linked with readline.
But if I install a binary package,
it comes with the @#$!%:-(~$ thing already there.

Looking at www.swi-prolog.rg/pldoc/man/section=readline
section B.10 tells me how to drive readline, but not
how to turn it off.
The Prolog flag readline(Bool) tells me whether SWI
Prolog was _linked_ with readline, not whether readline
is _active_.  Apparently, if readline is linked, it is
active.

?- current_prolog_flag(readline, B).
B = true.
?- set_prolog_flag(readline, false).
true.
<< play with readline >>
<< find it is still on >>
?- current_prolog_flag(readline, B).
B = false.

If the 'readline' flag means "SWI-Prolog is linked with
the readline library", as section 2.11 says, surely it
should not be alterable at run time?

If it is alterable at run time, shouldn't setting it to
false (temporarily) disable readline?

>> Documentation is a lot like test cases.  Writing it can uncover bugs.
> 
> Some things I rather leave undocumented.

Yes, but not, I hope, things that the user *has* to deal with.

Me, I cared enough about SWI Prolog documentation to buy the book.
Count your sales: *those* people care about your documentation.

>