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

[Zoltan Somogyi]

On 2024-05-02 18:16 +10:00 AEST, "Peter Wang" <novalazy at gmail.com> wrote:
>> +            ColorSpecs = color_specs(MaybeCorrect, MaybeIncorrect, MaybeCause),
>> +            (
>> +                MaybeCorrect = yes(Correct)
>> +            ;
>> +                MaybeCorrect = no,
>> +                Correct = color_8bit(40u8)          % This is green.
>> +            ),
>> +            (
>> +                MaybeIncorrect = yes(Incorrect)
>> +            ;
>> +                MaybeIncorrect = no,
>> +                Incorrect = color_8bit(203u8)       % This is red.
>> +            ),
>> +            (
>> +                MaybeCause = yes(Cause)
>> +            ;
>> +                MaybeCause = no,
>> +                Cause = color_8bit(11u8)            % This is yellow.
>> +            ),
> 
> I think the compiler should stick to the original 16 colors by default,
> (1) for compatibility, and (2) the original 16 colors are the ones that
> the user might tweak to taste.

I don't think your conclusion follows from your objectives.

As for (1), if all users have available on their terminals, the scheme
that is currently implemented does allow them to override the defaults
with a color that is drawn from the original 16 (or even the original 8) colors.
I would be extremely surprised if anyone nowadays used Mercury on a terminal
that is physically incapable of displaying 256 colors or more, so the only
reason why they wouldn't be able to handle a 256-color palette is that
they are using a crappy terminal emulator. I don't see any need to
cater to them at the expense of the vast majority of our users.

As for (2), yes, users can tweak the base 16 colors to their taste. However,
in all the terminal emulators I know about, and certainly in the one I use,
xterm on MATE, they cannot tweak them independently for different
programs they run in the terminal. The colors you want for e.g. syntax
coloring by vim may not be the ones you want for Mercury diagnostics,
and 16 colors are few enough that *if* you limit all uses to just those
16 slots, then conflicts are just about inevitable. And, the scheme I implemented
*does* let users tweak the colors Mercury uses to their taste, whether their
taste leads them to choose 3-bit or 4-bit colors, or 8-bit (or possibly later even 24-bit)
colors.

> It MIGHT be better to stick to the control codes 30-37,

Only if you dismiss the arguments above.

> and use the bold
> attribute for bright colors, for compatibility with older terminal
> emulators.

So far, all use of color by Mercury diagnostic is for color contrast,
not brightness contrast. I don't see any reason for this to change.
Until it does, I think this is moot point.

And *how much* older emulators are you talking about? I don't remember
precisely, but I think have had 256+ color emulators for at least two decades now.
Even the wikipedia page on 8-bit color says "Even though it is now outdated
for most consumer applications, 8-bit color encoding can still be useful ...".

Zoltan.