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

On 14/08/2013, at 9:55 PM, Jan Wielemaker wrote:
> 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.

The Solaris dbx debugger does this.
When you run a new version, it tells you that there are new
features and how to find out about them, and keeps on doing
this until you shut it up by setting

    dbxenv suppress_startup_message Version_Number

in your ~/.dbxrc file.  Then the next release starts
reminding you again.  Maybe something like

	user:message_property(new_features, after('6.1'))).

could do the job here?

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.
Example: I still work in Latin 1 rather than UTF8.  R really
wants to use UT8, so whenever I fire up the R gui it shows me
a message saying
	WARNING: You're using a non-UTF8 locale, therefore
	only ASCII characters will work.  Please read R for
	Mac OS X FAQ (see Help) section 9 and adjust your
	system preferences accordingly.
(The arrogance of demanding that I change *my* preferences to
suit a program, and the lapse of logic in claiming that Latin 1
characters won't work *because* I'm using a Latin 1 locale, are
a bit much to swallow.  But at least I get the warning.)

Oh yes, the R >>>GUI<<< is one of those pesky programs that
colourises the interaction in order to tell you stuff you
already know or is bleeding obvious.  My input gets coloured
blue (but I _know_ what that is, because I typed it, and it has
a prompt in front of every line), warning messages are coloured
red (but I can _see_ the "WARNING" word at the start of the line),
and all other system output is black (but R output and input
could only be mistaken for one another by someone with a bag over
their head).  It's colourising for the sake of colourising, not
for the sake of providing any useful information whatever.  At
least the R command-line program has the grace not to do that.

It _might_ be marginally useful when looking at someone else's
session, but copying the R GUI's colourised lines and pasting
them into TextEdit gives me straight black and white.  SWI Prolog
colourised interactions also turn into black-and-white when
copied and pasted into TextEdit.  In both cases this applies
regardless of whether TextEdit is in 'rich text' mode or not.


No, I don't propose writing the AppleScript necessary to dig out
the Terminal colours and compute contrasting things, because it
doesn't seem worth doing for just one operating system and just
one terminal emulator.

There's one thing still not clear to me about this feature.

%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])).

Colour  Line
black   ?- [library(lists)].
green   %  library(pairs) compiled into pairs 0.00 sec, 22 clauses
green   % library(lists) compiled into lists 0.00 sec, 122 clauses
purple  true.
- What is the message_property that controls the colour of the prompt?
- Of the user's input?
- Which is the property responsible for setting the purple line?
  The normal query response is surely not an error, a warning,
  or a debug message, and it's not green, so it cannot be
  information(al) either.
If someone wants to revert to the 60's with a two-colour ribbon in
their typewriter and have their input in red and the response in
black, what do they do?

I have checked http://www.swi-prolog.org/pldoc/man?section=printmsg
and honestly can't see anything that fits
"prompt-and-user's input" or
"normal-printing-the-solution".
It's not clear to me why the "true." response doesn't count as
"information that is requested by the user."


Documentation is a lot like test cases.  Writing it can uncover bugs.