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

[Zoltan Somogyi]

On 2024-05-05 13:11 +10:00 AEST, "Peter Wang" <novalazy at gmail.com> wrote:
> On Sat, 04 May 2024 00:25:19 +1000 "Zoltan Somogyi" <zoltan.somogyi at runbox.com> wrote:
>> 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
> 
> If you search for terminal color schemes or themes, you will find a
> plethora of schemes that people have created.

I know that; I did that search myself many years ago when I started using
syntax highlighting, and I know the pile would have grown a lot since then.

> What that says, I leave to you.

The existence of many people who create color schemes is perfectly compatible
with the idea that most people would prefer not to have to do that job.

>> > 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.
> 
> Right, this seems to be the heart of the disagreement. I don't care to
> configure the second half, the assignment of color slots to roles,
> assuming they are somewhat sensible (which they are).
> This applies to other programs, too.

For me, the "assuming they are somewhat sensible" part is the problem,
for the simple reason that in this instance, what is "sensible" is a question
of taste, and "de gustibus non disputandum", i.e. there is no point in
arguing about taste. The reason why I created a custom scheme for myself
is precisely the fact that I didn't like any of the ones I initially found,
and found more than a few to be downright ugly.

>> 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.
> 
> I would have proposed the same thing if you didn't change your mind.
> 
> My suggestion:
> 
>     --color-scheme=dark16|dark256|light16|light256
> 
>     MERCURY_COLOR_SCHEME (environment variable)
> (or theme instead of scheme; the two words seem to be used
> interchangeably)

I presume the difference between 16 and 256 is that

- the 16 versions use the 16 color slots that users can configure
  for themselves, and which are set up to use the 8 normal and 8 bright colors
  of the original 4-color VGA palette in the absence of such
  configuration, while

- the 256 versions use color slots 16-255 of the 8 bit color palette,
  which users can't reconfigure,

and in both cases, we would pick the slot numbers.

Are those presumptions correct?

Another question: what exactly do light and dark mean in these names?
Does "light" mean "light colors for dark backgrounds" or "dark colors
for light backgrounds"? Should the names be changed to disambiguate this?
lightbg and darkbg, perhaps?

> The "light" schemes would use normal (non-bright) colors, which look
> better on a light background.

Agreed.

> Bright yellow text, in particular, is
> completely unreadable on a white background.

Again, agreed. I will keep on using it for now, because I have to use
something. I can do a global replace of all the .err_exp files containing it
once we agree on a default scheme.

> Bright green and bright
> cyan are marginal.

I think green and cyan both have shades that are readable on
both white and black blackgrounds, and I would expect that
some of those shades would be on the 256-color palette, though
I have not yet verified this.

> If we abstain from using bright yellow text, the
> "dark" schemes would probably not be too objectionable on a light
> background.

Yes, it should be possible to pick color slots for which this is true.
If those slots are configurable and configured, then all bets are off.

> I think it's important that the compiler output be readable for everyone
> out of the box.

I agree that that is an important objective.

> That means either not enabling colors by default,
> or defaulting to a scheme that does not use bright yellow.

I am fine with either.

> FWIW, this is what I found in the GCC manual, in terms of the colors
> that they find acceptable to use by default:
> 
>      The default ‘GCC_COLORS’ is
>           error=01;31:warning=01;35:note=01;36:range1=32:range2=34:locus=01:\
>           quote=01:path=01;36:fixit-insert=32:fixit-delete=31:\
>           diff-filename=01:diff-hunk=32:diff-delete=31:diff-insert=32:\
>           type-diff=01;32:fnname=01;32:targs=35
>      where ‘01;31’ is bold red, ‘01;35’ is bold magenta, ‘01;36’ is bold
>      cyan, ‘32’ is green, ‘34’ is blue, ‘01’ is bold, and ‘31’ is red.
>      Setting ‘GCC_COLORS’ to the empty string disables colors.

I looked up the documentation of GCC_COLORS in "man gcc",
and I can say that the person who implemented colors for gcc
was definitely EVIL. My evidence for that assertion is that they
actually implemented *blinking text* :-)

I have no objection to having the main means of letting users
specify colors be a similar environment variable, though I would
strongly prefer for the env var to specify *only* foreground colors,
and not background color, or things such as bold. This is because
supporting multiple attributes (such as bold/nonbold, foreground color
and background color) that can be set independently, the code
required to implement the end of their scopes will need to be more complicated
than the code we have now, which is already complicated enough.

Zoltan.