Re: [PATCH] color: allow colors to be prefixed with "reset"

[Robert Estelle <robertestelle@gmail.com>]

> Unlike the "default" patch, I quite do not see the point of the example(s).

Yeah. This "reset" one was developed mainly as a hedge in case there
were concerns about the "default" one. You're correct that the
"default" one provides a finer-grained capability, and if we had to
choose, I'd go with that. However, the two are mutually compatible (no
conflicts, even) and complementary.

This "reset" approach seemed easier to go through since it just
generalizes the treatment of the existing "reset" capability without
introducing any new names or even SGR sequence numbers.

(The immediate goal of was to have some way to control from a color
whether to inherit or remove an existing background).

> Instead of saying "reset green", can't we already say "set bg to default, and set fg to green", thanks to the other one?

Yes-ish, however, "default" is just a color name: and like other
colors, it doesn't imply any attribute (bold etc) resets. Like, if you
turn on bold, and then change the color to red, you'll get bold red.
If you then change the foreground back to default, you'll have bold
whatever.

Instead, with "default", to avoid inheriting you could write:
   green default no-bold no-dim no-italic no-ul no-blink no-reverse no-strike
resulting in an ANSI sequence like: `\e[22;23;24;25;27;29;32;49m`

It's just a mouthful. `reset green` results in `\e[;32m`, which does
functionally the same thing. It's just the combination of "reset
everything" (``\e[m` or equivalently \e[0m`) followed by a color
(`\e[32m`).  I considered calling "reset" something like "only" since
that reads more clearly to me, but I also felt it was not worth the
cuteness when "reset" already existed and was defined consistently.

> Or does "default" do too little to deserve a name that implies "go back to default", e.g. by not defeating the 'blink' attribute that was set earlier?

I agree that "default" feels ambiguous. Within the current
positional-name format vs. e.g. "fg=green bg=default bold=on", I had a
lot of trouble thinking of a name that wouldn't be. However, "default"
is the same word as in the ANSI spec, used in console_codes(4) (see
heading "ECMA-48 Select Graphic Rendition here:
https://man7.org/linux/man-pages/man4/console_codes.4.html) and
ncurses (https://man7.org/linux/man-pages/man3/default_colors.3x.html).
I also explored a few terminals' settings to see if there was a better
name: usually they'll just refer to it unhelpfully as "foreground" or
"background", but when they're otherwise named it's usually like
"DefaultForeground".

Other names I'd considered had their own problems: "unset" could be
confusing alongside the existing "reset", "clear" could be confusing
as a foreground or in the context of translucent terms, "no-color" is
usually just untrue, and "normal" is (very confusingly, IMO) already
special-cased as a no-op word.

Best,
Robert

On Tue, Oct 26, 2021 at 2:42 PM Junio C Hamano <gitster@pobox.com> wrote:
>
> "Robert Estelle via GitGitGadget" <gitgitgadget@gmail.com> writes:
>
> > From: Robert Estelle <robertestelle@gmail.com>
> >
> > "reset" was previously treated as a standalone special color name
> > representing `\e[m`. Now, it can apply to other color properties,
> > allowing exact specifications without implicit attribute inheritance.
> >
> > For example, "reset green" now renders `\e[;32m`, which is interpreted
> > as "reset everything; then set foreground to green". This means the
> > background and other attributes are also reset to their defaults.
> >
> > Previously, this was impossible to represent in a single color:
> > "reset" could be specified alone, or a color with attributes, but some
> > thing like clearing a background color were impossible.
> >
> > There is a separate change that introduces the "default" color name to
> > assist with that, but even then, the above could only to be represented
> > by explicitly disabling each of the attributes:
> >   green default no-bold no-dim no-italic no-ul no-blink no-reverse no-strike
> >
> > Signed-off-by: Robert Estelle <robertestelle@gmail.com>
> > ---
>
> Unlike the "default" patch, I quite do not see the point of the
> example(s).  Instead of saying "reset green", can't we already say
> "set bg to default, and set fg to green", thanks to the other one?
> Or does "default" do too little to deserve a name that implies "go
> back to default", e.g. by not defeating the 'blink' attribute that
> was set earlier?