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

[Jim Porter]

On Tue, Aug 24, 2021 at 5:07 AM Eli Zaretskii <eliz@gnu.org> wrote:
>
> > +(defcustom ansi-bright-color-names-vector
> > +  ["gray30" "red2" "green2" "yellow2" "blue1" "magenta2" "cyan2" "white"]
> > +  "Colors used for SGR control sequences determining a \"bright\" color.
> > +This vector holds the colors used for SGR control sequences parameters
> > +90 to 97 (bright foreground colors) and 100 to 107 (brightbackground
> > +colors).
>
> I wouldn't offer a customizable list for this: users have no
> particular reason to redefine standard colors.

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.

> > +(defcustom term-color-bold-is-bright nil
> > +  "If set to non-nil, combining ANSI bold and a color produces the bright
> > +version of that color."
> > +  :group 'term
> > +  :type 'boolean
> > +  :version "28.1")
>
> Do we really need 2 separate knobs for these two features?  How
> probable is it that the same user will want to have bright colors in
> one package, but not in the other?

I doubt anyone would want to control these independently. It'd be nice
to have a single defcustom for this, but I wasn't sure where it should
go in that case. Would it be ok to use `ansi-color-bold-is-bright'
(from patch 1 in `ansi-color.el') in `term.el'? I see that `term.el`
requires `comint.el', which requires `ansi-color.el', so `term.el'
should see it without changing what gets loaded.

(It might even be nice to use the same definitions for the colors in
both `ansi-color.el' and `term.el', but that would take a bit of work
to migrate users'/themes' customizations. Maybe that's something to do
for Emacs 29 so I have time to figure out a good migration path.)