Re: [Nano-devel] about support for more than 16 colors

[Brand Huntsman]

On Mon, 8 Jan 2018 20:01:19 +0100
Benno Schulenberg <address@hidden> wrote:

> > maybe some names for the 216 colors, but using the gray0-23 style,
> > not 216 unique color names that no one can remember.  
> 
> Don't know about that.  I've tried with olive, lemon, salmon, and
> pink, but just like unbright yellow is far from yellow, many shades
> of those colors don't fit the name.

I couldn't come up with anything either.



Terminal colors can be configured by the user and nano doesn't check if 3 is 
actually yellow (it is often brown). I don't think nano should check for 
extended colors either. It would slow down startup and complicate the mapping.

I propose we support gray0 - gray100 (all 101 values) and map them to the gray 
colors, easy to do. #RRGGBB and #RGB will map to cube colors, unless all three 
channels are identical then map to gray colors (it produces more shades this 
way). The current color names will still map to base colors.

I also propose %RRGGBB and/or R-G-B percent-based colors are supported 
(alternate formats for cube/gray colors). The first uses channel values from 
0-99% but is scaled to 0-100. The second uses 0-100% channel values. Example: 
%994900 and 100-50-0. Might be easier for some to use these instead of #RRGGBB 
colors. There isn't enough resolution in the colormap for the %RRGGBB scaling 
to matter, but if only one could be supported I would choose the R-G-B format 
because it is easier to read.

The attached source code initializes gray, cube and base lookup tables and has 
functions to map RGB/gray colors to 8/16/88/256-color terminals. It also has 
functions to parse the four color formats mentioned above.

This will allow a syntax, using any of the five formats above, to work across 
all terminal types. Raw indices can also be supported but they would not be 
portable.

map-colors.c
Description: Text Data