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

[Peter Wang]

On Tue, 07 May 2024 10:09:35 +1000 "Zoltan Somogyi" <zoltan.somogyi at runbox.com> wrote:
> >> 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?

Yes.

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

> 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

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

Ok.

> > 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* :-)
> 

Right. (Though, they are just listing the attributes available via
SGR parameters.)

> 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.

I agree, we don't need to allow all that.

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.

Peter