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

[Peter Wang]

On Fri, 26 Apr 2024 20:44:51 +1000 Julien Fischer <jfischer at opturion.com> wrote:
> 
> 
> On Fri, 26 Apr 2024, Zoltan Somogyi wrote:
> 
> >
> > On 2024-04-26 19:28 +10:00 AEST, "Julien Fischer" <jfischer at opturion.com> wrote:
> >>> +convert_color_spec_option(OptionName, OptionValue) = MaybeColorSpec :-
> >>> +    % If/when we want to support 24-bit color, or indeed any form of
> >>> +    % color specification beyond 8-bit, we would do it here.
> >>> +    % (The options that specify colors are strings, not integers,
> >>> +    % specifically to make it possible to specify 24-bit colors
> >>> +    % as strings of the form "R-G-B".)
> >>
> >> It would probably be worth allowing the basic ANSI terminal colors to be
> >> specified by their usual names (e.g. black, red, green, yellow, blue etc)
> >> as well.
> >
> > That is a good idea, but we would need different names for e.g. colors 1 and 9.
> > One could be "red", and the other maybe "intense red" if "red" is color 1,
> > and some better name for "non-intense red" if "red" is color 9. Also, while
> > color 11 does look like intense yellow to me, its non-intense version, colour 3,
> > does *not* look like yellow to me.
> 
> What you refer to as "intense" red is usually referred to as "bright"
> red, so I suggest bright-red, bright-yellow for those versions.

The attribute is called "bold"; you'll see that in the configurations
for other programs (e.g. git diff). However, it's true that on any
terminal emulator, "bold" is implemented with brighter colours.

Not really suggesting to change it.

Peter