nano-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: David Ramsey
Subject: Re: [Nano-devel] [PATCH] index/RGB colors and italic/reverse/underline attributes
Date: Sun, 18 Feb 2018 20:16:49 -0600

Brand Huntsman:
> I posted a text file with the first round of patches and have attached
> it here for convenience.

Thanks; having the info about 256 colors in one place does keep things
easier.  I remember seeing it, but with all the discussion on the
subject, I lost track.

> Should this content be in a/the man page?

Probably.  If it's not obvious to advanced users without a lot of
research elsewhere, less technical users without the time and/or
patience to do the research elsewhere will be even worse off.  It's been
enough of a mess on my end just getting X11-based terminals of different
types to all use 256-color mode in the first place.

> There are only 4 color shades per channel on 88-color and 6 color
> shades on 256-color. Any color you plan on distributing should only
> use those 4-6 shades, or you risk it not mapping properly between 88
> and 256 terminals. Grayscale colors have many more cases and that file
> documents the most portable.

Understood.

> You can use any RGB color you want, but it will always be mapped to
> what the terminal supports. Your 50 and F0 are mapped to 55 and FF on
> 88 and 256 color terminals. But your A0 is mapped to BB on 256-color
> and to 55 on 88-color. Using BB would produce more similar colors on
> both terminals. But keep in mind, the shade used on 88 or 256 is not
> actually 55, 77, BB or CC. Those are simply single-digit values I
> chose to most represent the shade across 88/256 terminals.

That's good to know.  It doesn't have to be exactly the right shade,
just close enough.  Especially since I know palettes can differ even in
16-color modes (for "yellow" versus "brightyellow", some palettes show
the former as "brown" and the latter as "yellow", the way the old IBM PC
does).

So with those changes, the colors should be:

set functioncolor bold,#00bbff
set keycolor bold,#bb00ff
set numbercolor bold,#bb00ff
set statuscolor bold,brightwhite,#5500bb
set selectedcolor bold,brightwhite,#0055bb
set titlecolor bold,brightwhite,#5500bb

And this does work well enough for me; thanks again.  Outside of
256-color mode, I still get dark blue in place of #5500bb and #0055bb,
as you pointed out, but the other colors are much closer, so it works
better than it did in that case.

> Mapping to 8/16 color is a gamble because those colors are usually
> redefined by the OS/distro, terminal or user. The brightwhite in your
> example might not actually be pure bright white. Using #FFF or #FFFFFF
> on 88/256-color terminals will use a code other than 15 which should
> always be pure bright white, unless the user changed the extended
> colors too. So mixing named colors and RGB colors will not produce the
> same theme across systems.

As long as it's white enough to be recognizable as whitish, it'll be
fine by my standards.

> We could support a fallback color for index and rgb colors.
> # index:namedcolor
> # #rgb:namedcolor
> set titlecolor bold,#FFF:brightwhite,#50A:magenta
>
> On 8/16-color terminals it would use the named color, if given. But
> you would still need to use semi-portable colors for 88/256. Extending
> it to provide a color for every terminal type could get verbose,
> especially down the road when ncurses gets 24bit support.
>
> # 24bit:256:88:8/16
> set titlecolor #FEFEFE:#FFF:#FFF:brightwhite

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.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]