bug#50179: [PATCH] Add support for "bright" ANSI colors to ansi-color and term-mode

[Eli Zaretskii <eliz@gnu.org>]

> From: Kévin Le Gouguec <kevin.legouguec@gmail.com>
> Cc: Jim Porter <jporterbugs@gmail.com>,  50179@debbugs.gnu.org
> Date: Wed, 25 Aug 2021 09:06:35 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> I made this a defcustom because `ansi-color-faces-vector' and
> >> `ansi-color-names-vector' are defcustoms too. More practically
> >> speaking, I'd want to customize this new variable to make these colors
> >> match the Emacs theme I use. I chose colors in this patch to
> >> complement `ansi-color-names-vector', but they'd clash with my theme.
> >
> > How can named colors change with the theme?  Faces can, but colors are
> > absolute.  Bright-yellow is the same color whatever the theme.  At
> > least IMO.  I wonder if others think otherwise.
> 
> FWIW, a couple of Emacs's built-in themes set these ansi-color options.
> See e.g. the Modus themes, which are designed to meet WCAG's highest
> standards for colour contrast.

It's OK to set a variable.  I was asking why would we want to offer
users the opportunity to customize these translations.

> Maybe there's an analogy to make with terminal emulators?  Most of those
> (e.g. Konsole, Terminator, Xfce's) allow the user to customize the
> 16-color palette.

Once again, if someone _really_ wants that, they can set a variable
allright.  I'm asking why would _we_ want that.

> Digging into the history of this 4-bit palette[1], it almost seems like
> no two consoles ever used the exact same colors, so these color names
> might not be as absolute as say, HTML color names[2].

I don't see how this justifies a desfcustom, sorry.  If there's no
110% consensus, we can choose whatever similar color we want.