[m-dev.] MERCURY_ENABLE_COLOR

[Peter Wang]

On Fri, 14 Jun 2024 15:15:39 +1000 "Zoltan Somogyi" <zoltan.somogyi at runbox.com> wrote:
> At the moment, you can use environment variables to specify
> a color scheme or to disable the use of color, but not to enable
> the use of color. I don't think that just doing "unset NO_COLOR"
> is an adequate solution, because you may want to enable color
> in Mercury diagnostics without necessarily enabling it for any other
> program.
> 
> Would people object if I added code to insert --enable-color-diagnostics
> into the command line if the envvar MERCURY_ENABLE_COLOR is set
> and nonempty, at the position where we now insert its opposite
> if NO_COLOR is set and nonempty?
> 
> The reason I ask is that I think the color diagnostics are now as ready
> as I can make them, so I would like to switch them on by default. For that,
> I need to document them, and for *that*, I would like the system to be
> documented to be in its final form.

I find --enable-color-diagnostics to be long. Some GNU programs and
others have --color=auto|always|never, where the default value 'auto'
enables color if standard output or error (depending on the program)
is a terminal.

A problem is that the Mercury getopt module doesn't support optional
arguments. In those other programs, "--color=WHEN" must be a single
argument with the equals sign, which allows "--color" by itself to be an
abbreviation for "--color=always". In the Mercury compiler, a "--color"
option (no equals sign) would always consume the next argument on the
command line, which might break expectations.

Anyway, if we had the --color option, it would make sense for the
environment variable to accept the same values, i.e.
MERCURY_COLOR=auto|always|never.

Even if we didn't have the --color option, I think it still makes sense
for the environment variable be able to enable *or* disable color.

Peter