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

On 16 Aug 2013, at 08:41, Jan Wielemaker <[email protected]>
 wrote:

> 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

I just want to state for the record, I *like* using terminals.
I can do lots of things from the terminal without having a lot
cr*p all over the screen. I can use GNU screen 
and have all my terminal sessions accessible from any machine
regardless of whether or not the GUI system or X11 is up or
down or crashed. I *don't* like GUIs, or, in most cases, windows.
They go all over the place and make a big mess. They force you
to muck about with the mouse. They hide each other. 
On X11 I use a tiling window manager (Ion 3), which improves
things a bit, but not for Mac Apps.

Sorry if I sound a bit touchy about it, but this reminds me of
a process that the Mathworks went through with MATLAB a while ago. 
It all started with "Future versions may not support X11 graphics",
or words to that effect. A few years down the line and X11 graphics 
have indeed gone.  I can no longer arrange my (many) plot windows 
neatly and with minimal chrome using Ion 3 under X11; instead
they just blorp out all over the screen, with their nicely shaded 
title bars and pointless buttons, and now all Matlab graphics require
Java, for which the word 'bloated' is woefully inadequate. At least this 
would be the case if I hadn't stuck with an older version of Matlab.

So, feel free to develop Qt console, but *please* don't turn terminal 
SWI into a second class citizen!

Samer.

ps. I'm not worried about the terminal colours issue. I'm happy
just to set the terminal emulator preferences so that all the colours
are legible on the chosen background and be done. It's not the
actual colours that are important, only that stuff can be made to 
look different.

> 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.
>> 
>>> 
> _______________________________________________
> SWI-Prolog mailing list
> [email protected]
> https://lists.iai.uni-bonn.de/mailman/listinfo.cgi/swi-prolog
>