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: Tue, 27 Feb 2018 18:05:30 -0600

Brand Huntsman:
> Index colors can't be translated at all, there is no context what the
> number represents.

Okay.  I've apparently been misunderstanding what the three-digit hex
values mean.  See below.

> 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.

I figured this much.

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

In this case, I meant some minimum description of what the options do,
and maybe a few examples of the most complex bits.  Just enough to make
it a bit more understandable for those without all of your curses
knowledge (which, if I had it, I'd have used it to help implement 256-color
support by now) :) Not full docs at this point, of course.

> 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?
> :)

Got it. :) So, in my example, the colors can be simplified from, e.g.:

set titlecolor bold,brightwhite,#5500bb:magenta

to

set titlecolor bold,brightwhite,#50b:magenta

> 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.

Yes, and I didn't know it was this problematic.  So I'd have to start
the terminal with, say TERM=xterm-88color in order to test it properly,
instead of setting it after the fact?  Or do I just build urxvt with
only 88-color support, as you mention below, and test it with that?

> There isn't really anything we can do to fix an incorrect TERM value.

Okay.  Another unfortunate difference between how things *should* work
and how they *actually* work.

> 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.

Okay.  I'll have to try that.

> 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...

Okay.  It seems a lot of it relies on multiples of hexadecimal 11, which
of course easily translates between #RGB and #RRGGBB.



reply via email to

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