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

On 08/14/2013 02:52 AM, Richard A. O'Keefe wrote:
>
> On 13/08/2013, at 6:56 PM, Jan Wielemaker wrote:
>> There are two ways to control this.  Here are some entries:
>>
>>   * message_property/2 allows changing the colour for message `types'.
>>   * The Prolog flag color_term can be set to `false`.  That is most
>>     likely your best option.
>
> (1) Could we be allowed to use English spelling for this
>      as well as Merkin speling?

Two flags ...  Maybe time for Esperanto :-)

> (2) The documentation really needs an index.  When I got the printed
>      copy, I was hoping for an index in that.  The on-line manual's
>      search box failed to report color_term when I sought 'color'.

Fixed this one by updating the FAQ page at 
http://www.swi-prolog.org/FAQ/ColorConsole.txt and adding a tag to it.

> (3) Maybe that's because help(current_prolog_flag) lists a whole lot
>      of flags, but 'color_term' is not one of them.  This is in version
>      6.5.0.

This flag should be in the main docs.  It wasn't because it is created
by a library that had a quite experimental status for a long time.

>>> Whatever the default colours are, they should be chosen to *contrast*
>>> with the user's Terminal settings, and if it is impractical to detect
>>> that, the best default is no colouring.
>>
>> I don't think there is a way to get this info.
>
> I am specifically writing about Terminal.app in Mac OS X.
> Poking around with AppleScript Editor, I found these
> properties that you can ask Terminal for:
>
>    cursor color (color) : The cursor color for the tab.
>    background color (color) : The background color for the tab.
>    normal text color (color) : The normal text color for the tab.
>    bold text color (color) : The bold text color for the tab.

Well, if you write a library that fetches these things and dynamically
creates a suitable color scheme, I'll add it.

>>    Some emulators allow for
>> redefining the 16 ANSI colors, which might solve some of the problem, but
>> makes it impossible to guess the result of specifying colors.
>
> The way out is to go up.  (One of my favourite sayings.)
>
> There may well be some people who like their code colourised to
> tell them things they already know.  (Hey, I can _see_ the percent
> sign.  It's right at the beginning of the line.  Why does it have
> to be a different colour as well?  I _know_ this line is something
> I typed and this other line is _not_ something I typed.  Why do
> they have to be different colours?  Why not use colours to tell
> me something I _don't_ know?  Why not make the colours _useful_?)
>
> But it passes the bounds of belief that they will all like the *same*
> colours.  The answer is obvious.  Let people specify the colours they
> want in their ~/.plrc, and if they _don't_ say what colours they want,
> give them uncolourised text *and* a note in the banner something like
> "See color_term in current_prolog_flag/2 for a colourised interaction."

The skeleton for ~/.plrc contains this snippet:

%	Use the flag below to  disable   coloured  output  in all cases.
%	Normally,  coloured  output  is  enabled  if  the  output  is  a
%	terminal.

% :- set_prolog_flag(color_term, false).

%	Specify colors for the above,  based   on  the  message kind See
%	ansi_format/3 for specifying visual  effects.   The  table below
%	duplicates the default behavior.  Notably   on  terminals with a
%	dark background, yellow might be a   better  choice for warnings
%	and errors.

%:- multifile user:message_property/2.
%
%user:message_property(informational, color(fg(green))).
%user:message_property(information,   color(fg(green))).
%user:message_property(debug,         color(fg(blue))).
%user:message_property(warning,       color(fg(red))).
%user:message_property(error,         color([fg(red),bold])).

What would be nice is to have a nice way of finding these snippets.
Maybe by providing each config snippet as separate files and provide a
menu when editing ~/.plrc that allows inserting these?

P.s. the recent one is always in swi('customize/dotplrc').

>> But today, quite a few applications color by default
>> and I have the impression that most people like it.
>
> Where does green text on a green background *ever* get to be sensible?
>
>> You'll always make some
>> people unhappy with whatever default preference you choose ...
>
> Well, that's not what made *me* unhappy.
> What made me unhappy was not being able to find anything about it in
> the documentation.  If the banner had said "hey there's this new
> colourising feature, read about it at <link>", I would have been
> *briefly* irritated.  As it was, I lost nearly an hour trying to
> figure out what to do, diligently searching documentation, and
> *failing*.

It might be an idea to make people automaticaly aware of new features.
Possibly this can be combined with Carlo's new console. It requires a
bit of automation though. Maybe something with the GIT commit messages
would be feasible, similar as to how change messages are generated from
there.

> There are new features that don't affect anyone who doesn't choose
> to use them, and they can stay undocumented while the design is
> finalised.  But new features that change the user experience really
> do need to be documented.
>
> Having got that off my chest, this is an exceptional case.
> If the documentation of SWI Prolog were generally dreadful, this
> issue would be a minor point.  But the documentation of SWI Prolog
> is almost always _there_ and _useful_.

That is good to hear.  I had almost forgotten :-)  Getting a better,
especially the online version, has high priority.  Given the amount
of documentation though, this is a big challenge.

	Cheers --- Jan