Re: [Nano-devel] [PATCH] index/RGB colors and italic/reverse/underline attributes

[Brand Huntsman]

On Sun, 18 Feb 2018 20:16:49 -0600
David Ramsey <address@hidden> wrote:

> Outside of 256-color mode, I still get dark blue in place of #5500bb
> and #0055bb

On 8/16-color, each RGB channel is mapped from 0-255 to 0-4, using
c_shades[] (dark - 10% / 25% / 30% / 25% / 10% - bright), and then
looked up in _low_color_cube[]. It uses the same layout as 88/256-color cubes: 
blue channel is incremented from left->right, green from top->bottom of each 
cube and red from first->last cube. I only selected a bright color if one of 
the channels was a 4. And dark channels are ignored if the other channels are 
more than about 1 above it.

One improvement you just reminded me about is to not convert 8-15 values in 
that table to 0-7 on 8-color terminals. It can do exactly what 8-15 index 
values do and set the bright flag. I'll release a new rgb-color patch soon for 
this.


> > We could support a fallback color for index and rgb colors.
> > # index:namedcolor
> > # #rgb:namedcolor
> > set titlecolor bold,#FFF:brightwhite,#50A:magenta
> >
> > Extending it to provide a color for every terminal type could get
> > verbose, especially down the road when ncurses gets 24bit support.
> 
> A color for every terminal type definitely would get verbose, yes.  I
> was thinking of just a fallback for 8/16-color mode if anything more
> than that isn't available, since 8/16 colors seems to be the lowest
> common denominator if we have color at all.

It would also make it easier to approximately determine what color an RGB/index 
value is, for those who can't fluently read them. And even more so for index 
colors, and while not portable, it would be nice if you had to ssh into a 
machine with index colors from an 8/16-color machine.

Should we require the ":namedcolor" for all index/RGB values? It would prevent 
accidental use of RGB colors without a fallback in default syntaxes and make 
third-party distributed syntaxes more portable.