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

[Brand Huntsman]

On Tue, 27 Feb 2018 08:50:47 -0600
David Ramsey <address@hidden> wrote:

> So support for only hex values for indexes is really because the hex
> values are easier to translate?  (See below.)  Also, further down the
> line, if enough terminals get support for 24-bit color, that should be
> in #RRGGBBAA format, so it probably would have a similar mapping
> downgrade on lower-color systems, right?

Index colors can't be translated at all, there is no context what the number 
represents. And lack of support in ncurses is why these patches don't do 24bit 
color. When it gets support, #RGB and #RRGGBB can use 0xFF as the alpha 
channel. And 4 and 8 digit support can be added to specify alpha channel, if 
ncurses and terminals actually use an alpha channel in the color. I would 
imagine they don't, and they would have a whole window alpha channel to fade 
all content. But I don't know anything about that...


> Although all this should be mentioned in the nanorc documentation in
> some form, since it is still somewhat complex (and having examples of
> it definitely makes it easier to understand, at least on my end).

That only matters if the patches are accepted. And writing documentation for 
continually changing test features is a waste of time.


> how do your index/RGB color fallbacks work in some cases?

Support for index colors was removed in these new patches.


> For example, your errorcolor entry uses the hex value #b00, which in
> 256-color mode produces a dull red (which I'm assuming is #b00b00 or
> close to it).  In 88-color mode, it produces a dull cyan instead.  I'm
> guessing the latter is another case of colors' not mapping perfectly
> between different color sets.

3-digit values are "stretched" to 6-digit, not repeated. So #123 is identical 
to #112233. And #b00 is #bb0000. r_g_b = rr_gg_bb, got it? :)

Did you switch your 256-color terminal to an 88-color TERM value? Because the 
terminals I have don't work like that. The terminal always uses its 256 color 
palette so any program that thinks you only have 88 colors will only use the 
lower 88 indices (of the 256-color palette), which are obviously not the same 
palette as a real 88-color terminal. There isn't really anything we can do to 
fix an incorrect TERM value. Similar to how my xterm uses ALT to add accents to 
characters instead of being a meta key.

I have urxvt compiled without 256-color support, so it only supports 88-color. 
And xterm which supports 256-color. #b00 is #af0000 on xterm and #cd0000 on 
urxvt, both a form of red. And setting TERM=rxvt switches urxvt to 8-color mode 
and the :red fallback kicks in.

   88  256
0  00  00
5  8B  5F    darker on 256
7  8B  87
B  CD  AF    darker on 256
C  CD  D7
F  FF  FF

If you want colors to be more similar between 88 and 256, you would want to use 
7 or C. But if you want the colors to be a little darker then use 5 or B and 
256 will be darker but 88 will be a little brighter. I've updated the 
rgb-colors to better reflect this, so if documentation is ever written...