[m-rev.] for review: options to control the use of color

[Zoltan Somogyi]

On 2024-05-03 17:27 +10:00 AEST, "Peter Wang" <novalazy at gmail.com> wrote:
> On Thu, 02 May 2024 19:44:21 +1000 "Zoltan Somogyi" <zoltan.somogyi at runbox.com> wrote:
>> 
>> On 2024-05-02 19:34 +10:00 AEST, "Peter Wang" <novalazy at gmail.com> wrote:
>> > On Thu, 02 May 2024 18:40:23 +1000 "Zoltan Somogyi" <zoltan.somogyi at runbox.com> wrote:
>> >> As for (2), yes, users can tweak the base 16 colors to their taste. However,
>> >> in all the terminal emulators I know about, and certainly in the one I use,
>> >> xterm on MATE, they cannot tweak them independently for different
>> >> programs they run in the terminal.
>> > 
>> > Yes, but that's kind of the point. I can pick a palette of 16 colors
>> > that work well together, and expect programs to stick to that palette
>> > (obviously in the past there was no choice).
>> 
>> Users can pick the palette, but they can't pick which color will be used
>> for what purpose.
> 
> I'm not arguing against allowing the user to configure which color
> for what purpose.

I didn't think you were. I was attempting to point out the reason for
why I think we are talking past each other. You are using the phrase "color scheme"
to mean "use these 8 colors as the colors to display for the escape sequences
CSI 30 to 37", or maybe "use these 16 colors to display for CSI 30 to 37 and
90 to 97". I am saying that this is not enough, because this does not, and CANNOT,
achieve BY ITSELF what a user like me probably wants to accomplish, which is
something like "I want vim color syntax highlighting to use red for characters
past column 79, green for clause heads, yellow for string constants etc" AND
"I want mmc to use red for incorrect, green for correct and yellow for possible
error causes". This is because it is up to the code of vim and of mmc to pick
which CSI escape sequence they use for each purpose. If e.g. mmc pics
CSI 31 (which is red by default) to display incorrect code, but vim, through
a vim syntax file, picks CSI 31 as the color to use for clause heads, and NOT
as the color to use for chars past column 79, then THERE IS NO WAY
you select the exact shade of red you like to get what you want with both
programs simulatenously just by that action. Instead, you will have to do
something to override the default in what one might call "role assignment".
And as soon as you do that, the default does not matter much anymore,
since you are explicitly ignoring it.

>> > As it is, the Mercury compiler wants to use THIS green, THIS red, THIS
>> > yellow. Why can't it just use the green/red/yellow that I've already
>> > chosen, without me having to override it? It's not like it's drawing a
>> > picture where no other shade will do.
>> 
>> My point is: people who want that *can* override the Mercury default,
>> and this is a minute or two to look up the Mercury options, and add
>> an entry to an Mmakefile or Mercury.options file. I believe that imposing
>> this cost on the very few people who I expect would want to do this
>> is preferable to imposing the same cost on the (I expect) larger number of people
>> who don't want to be limited to the strong primary colors in the default 3-bit palette,
>> which (on my terminal emulator, and on probably others) don't look so good.
>> 
> 
> That's a good argument for configuring your terminal emulator to use a
> palette that you DO like, not to configure each program separately.

As explained above, I am not talking about configuring the color palette.
I am talking about configuring the color role assignment.

>> >> The colors you want for e.g. syntax
>> >> coloring by vim may not be the ones you want for Mercury diagnostics,
>> >> and 16 colors are few enough that *if* you limit all uses to just those
>> >> 16 slots, then conflicts are just about inevitable. And, the scheme I implemented
>> >> *does* let users tweak the colors Mercury uses to their taste, whether their
>> >> taste leads them to choose 3-bit or 4-bit colors, or 8-bit (or possibly later even 24-bit)
>> >> colors.
>> > 
>> > Will the diagnostics really need that many different colors?
>> 
>> It uses four. The point is that *other* uses, such as syntax highlighting,
>> already use all the available 3-bit colors, so even using one color by Mercury
>> causes interference.
> 
> I don't understand. I think there has been a misunderstanding.

As the above part of my reply implies, I agree.

> I am not suggesting to prevent users from using more than the basic
> 16 ANSI colors.

I didn't think you were.
 
> It is very common to select a "color scheme" in a terminal emulator,
> which picks a color for each of the 16 ANSI color "slots".

I have little personal experience with that. On my work laptop,
on which I use Mate and xterm, selecting the colors to go into those
16 color slots is a pretty bad experience, precisely because it does
only half the job. It lets you pick the color to go into e.g. slot 5,
but does not, and cannot, tell you what any particular program,
such vim with a particular syntax file, will use the color in that slot FOR.
So there is no way to pick the colors you want except by trial and error.
And to top it all off, picking your preferred color scheme requires
and entails setting up a "custom" color palette, but (as far I can tell)
there is no way to actually SAVE this color palette anywhere. If you
want to switch away even for a moment to try out e.g. the "xterm"
or the "linux console" palette, there is NO WAY to get your possibly
painfully set up custom palette back. I say "painfully" because when
you click on a color slot in an attempt to change the color in that slot,
the pop-op window you get gives you a sea of colors but gives you
absolutely no clue about what clicking one of these colors would do.
You have to figure it out by trial and error, which usually involves
a nontrivial amount of cursing.

On my Mac, the color preferences just let you pick your 16 colors.
It also does not tell you what each will be used for; it can't, since
there are far too many programs whose settings it would need
to know about, including programs that did not exist or whose
color role assignments have changed since that preferences
panel was coded. At least it does not seem to let you destroy
your custom setup with a single click.

I have no idea whether things are so bad on other setups,
but these experiences with two reasonably common systems
lead me to believe that many people probably have a selection of colors
in the standard 16 slots in their terminal that they treat as a black box
that is not worth messing with

> Any other colors beyond the basic 16 are not configurable
> (that I have seen), and who would want to pick 256 colors anyway?

Nobody. But that is not the same thing as "picking four colors from
a selection of 256".

> Programs that use the basic 16 ANSI colors will produce output on the
> screen that follows the user's chosen color scheme.

... that will use the user's chosen color palette. That palette, if it was
set up by the user, it was almost certainly set up to get the right overall
*color assignment* by some program other than mmc, since users
would need clairvoyance to set them up for mmc :-)

> The vast majority of
> command-line programs do this (including ls, grep, gcc, clang, ...),
> which is good, and expected. Otherwise, what would be the point of
> creating or picking a color scheme if programs ignored it?
>
> Programs which produce output using colors beyond the basic 16 will NOT
> follow the user's color scheme.

Trivially true, but for the reason listed above, also irrelevant in many cases,
the cases where different programs use incompatible color assignments.
(It is up to the users' taste what they view as incompatible.)
 
> I'm asking that the Mercury compiler respect the user's chosen color
> scheme by default, like most programs. That's it.

Except users have chosen only a colors to go into the slots; the other half of
the color scheme, the assignment from color slots to color roles,
they have not chosen.

I can see a way to resolve this impasse, which is: Mercury should have
TWO sets of default colors. Mercury has (now) four color names:
color_incorrect, color_correct, color_cause and the new color_subject.
One default scheme would map each of these to one of the 16 color
numbers, which correspond to CSI 30-37 and CSI 90-97, or, equivalently,
to CSI 38 0-15. These color numbers are controlled by the user, using
e.g. xterm preferences. The other default scheme, the current one, would
map these color names to colors chosen by the us, the Mercury implementors,
from the 256-color palette of CSI 38. Users could then chose the "default to use"
by either an mmc option, or by a set-and-forget environment variable.
tools/bootcheck would of course have to use the default that does not depend
on the possibly-nonstandard color setup of the user running it, but can easily
set, or not set, the required env var.

It is obvious that Peter will vote vote for the first default as the "default to use"
by default, the "default default" if you will, while I will vote for the second.
That makes Julien the tie-breaker.

I leave it up to you guys to propose the names of the options and env  vars,
provided of course that you accept this compromise.

Zoltan.