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

I think there are more urgent things to document, fix and
implement ...  To get rid of readline in a binary build,
use "swipl -tty".  That also gets rid of single-keystroke
commands.

Soon, the terminal based SWI-Prolog will be mostly for server
and scripting applications.  Carlo's Qt base console will be
the default interaction console on all platforms.  With some
luck, there will be a real Mac App that can be run from the
dmg file, be installed anywhere and opens a nice window :-)

The first version looks like the Windows swipl-win.exe.  Carlo
has ideas what future versions will look like :-)

	Cheers --- Jan

On 08/16/2013 01:01 AM, Richard A. O'Keefe wrote:
> 
> 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.
> 
>>