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

[Peter Wang]

On Thu, 02 May 2024 19:44:21 +1000 "Zoltan Somogyi" <zoltan.somogyi at runbox.com> wrote:
> 
> On 2024-05-02 19:34 +10:00 AEST, "Peter Wang" <novalazy at gmail.com> wrote:
> > On Thu, 02 May 2024 18:40:23 +1000 "Zoltan Somogyi" <zoltan.somogyi at runbox.com> wrote:
> >> 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.
> > 
> > Yes, but that's kind of the point. I can pick a palette of 16 colors
> > that work well together, and expect programs to stick to that palette
> > (obviously in the past there was no choice).
> 
> Users can pick the palette, but they can't pick which color will be used
> for what purpose.

I'm not arguing against allowing the user to configure which color
for what purpose.

> > As it is, the Mercury compiler wants to use THIS green, THIS red, THIS
> > yellow. Why can't it just use the green/red/yellow that I've already
> > chosen, without me having to override it? It's not like it's drawing a
> > picture where no other shade will do.
> 
> My point is: people who want that *can* override the Mercury default,
> and this is a minute or two to look up the Mercury options, and add
> an entry to an Mmakefile or Mercury.options file. I believe that imposing
> this cost on the very few people who I expect would want to do this
> is preferable to imposing the same cost on the (I expect) larger number of people
> who don't want to be limited to the strong primary colors in the default 3-bit palette,
> which (on my terminal emulator, and on probably others) don't look so good.
> 

That's a good argument for configuring your terminal emulator to use a
palette that you DO like, not to configure each program separately.

> >> 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.
> > 
> > Will the diagnostics really need that many different colors?
> 
> It uses four. The point is that *other* uses, such as syntax highlighting,
> already use all the available 3-bit colors, so even using one color by Mercury
> causes interference.

I don't understand. I think there has been a misunderstanding.

I am not suggesting to prevent users from using more than the basic
16 ANSI colors.

It is very common to select a "color scheme" in a terminal emulator,
which picks a color for each of the 16 ANSI color "slots".
Any other colors beyond the basic 16 are not configurable
(that I have seen), and who would want to pick 256 colors anyway?

Programs that use the basic 16 ANSI colors will produce output on the
screen that follows the user's chosen color scheme. The vast majority of
command-line programs do this (including ls, grep, gcc, clang, ...),
which is good, and expected. Otherwise, what would be the point of
creating or picking a color scheme if programs ignored it?

Programs which produce output using colors beyond the basic 16 will NOT
follow the user's color scheme.

I'm asking that the Mercury compiler respect the user's chosen color
scheme by default, like most programs. That's it.

Peter