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

[Zoltan Somogyi]

On 2024-05-07 16:25 +10:00 AEST, "Peter Wang" <novalazy at gmail.com> wrote:
> Also, some or all of these could be equivalent to disabling color
> (unless overridden by another option):
> 
>     --color-scheme=none
>     MERCURY_COLOR_SCHEME=""
>     MERCURY_COLOR_SCHEME=none

"none" I definitely agree. I am not sure about MERCURY_COLOR_SCHEME="".
While any shell scripts I write use sh/bash, my interactive shell has been tcsh
for about three decades now. I know how to unset an env var in tcsh:
just "unsetenv varname". I don't know how to do that sh/bash. Does an
assignment of the empty string to a sh or bash var, followed by an export
of the var unset the environment variable, or does it just set it to the empty string?
And if the latter, how *do* you unset an envvar in sh/bash?

>> 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?
> 
> I don't think that's necessary. CSS, mobile devices, and many applications
> all have a "dark mode" or "dark themes", which refer to a light-on-dark
> color scheme.
> https://en.wikipedia.org/wiki/Light-on-dark_color_scheme

I agree that "dark mode" is clear on this point. I don't think "dark16" is.
That said, I wouldn't object to including "mode" in the name of the scheme.

>> 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* :-)
>> 
> 
> Right. (Though, they are just listing the attributes available via
> SGR parameters.)

Yes, I know. I still think it is evil, for the same reason Nazi generals
saying "I was just obeying orders when I ordered the POWs to be shot"
was evil.

> If we *did* introduce an environment variable similar to GCC_COLORS,
> would you keep the --set-color-* options as well? I think very few
> people would be using either; we needn't dedicate that much code and
> documentation to configuring colors.

We will want the options anyway. Without them, every error_spec being
written out will need to parse the envvar's text to find the color shades to use.
That would not be a problem, except you have to be prepared for the parse
to fail, in which case you want to report its failure. However, you don't want to
report it a dozen times if the program wants to print a dozen diagnostics.

The simple way to handle this is to parse the env var just once in handle_options.m,
report any errors in that parse at that time, record the results of the parse,
or the results of the recovery process from any parse errors, in the option table,
and then let the rest of the compiler get its color info from those options.

Normally, we would actually record this info in specialized parts of the
globals structure, i.e. in the parts that are NOT the option table, but in this case,
we can't do that. The reason is that write_error_spec.m has to work when
all it has is an option_table. And the reason for *that* is to enable it to
report the errors that handle_options.m can discover while it is deciding
what should go into the very first globals structure.

Given that we need the options for internal purposes, giving them names
that allow them to be used from command lines should cost us only a few lines
of documentation in options.m and user_guide.texi.

Zoltan.