[m-dev.] MERCURY_ENABLE_COLOR
Zoltan Somogyi
zoltan.somogyi at runbox.com
Fri Jun 14 17:19:51 AEST 2024
On 2024-06-14 17:04 +10:00 AEST, "Peter Wang" <novalazy at gmail.com> wrote:
> I find --enable-color-diagnostics to be long.
I have no objection to shortening it to just --color-diagnostics. (Though even
that is longer than what I used during my testing, which was $ecd :-)
And --no-color-diagnostics reads even better than --no-enable-color-diagnostics.
> 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.
Agreed. But since getopt limitations force the condition in that statement
to be false, it does not support the conclusion.
> 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.
An environment variable does already do that: NO_COLOR.
I don't object to setting MERCURY_ENABLE_COLOR=never
or MERCURY_ENABLE_COLOR=no having the same effect.
I just don't see the need. But I don't object either, so pick
the mapping from MERCURY_ENABLE_COLOR values to
on/off and I will implement it.
Zoltan.
More information about the developers
mailing list