Re: [Nano-devel] [PATCH] various color tweaks

[Brand Huntsman]

On Sun, 4 Mar 2018 11:53:50 +0100
Benno Schulenberg <address@hidden> wrote:

> Op 03-03-18 om 02:22 schreef Brand Huntsman:
> > The first patch might reduce memory on 64bit platforms.  
> 
> I'm not much interested in reducing the memory usage of nano.
> Nano uses shitloads of memory anyway, reading in *all* of the
> syntaxes (some distros do that by default).

You should be, it helps nano run better on low-end devices and using excess 
memory can slow it down. I'd like to remove fg/bg from colortype, but I know it 
wouldn't make a difference on 32bit or 64bit. Without bright it uses 40/60 
bytes, and would need to get down to 32/48 to reduce memory.


> > +           (beforenow->attributes & 0xFFFF0000) !=
> > +                   ink->attributes))  
> 
> It is unclear what this does.  Apparently you have figured out that
> actual attributes, like A_BOLD and A_REVERSE, live in the upper 32
> bits of the color thingy.  But is that true also for older ncurses?
> Didn't it limit color pairs and attributes to 16 bits each?

0xFFFF0000 is the upper 16 bits of a 32bit value. I think it has always been 
that way. The ABI 6 change has something to do with cchar_t getting bigger.

It is good you brought it up though, why was nano comparing bright there?!?! A 
color pair is only the fg and bg values, it has nothing to do with attributes 
(they are OR'd with the color pair later on). Nano is currently creating two 
color pairs for "red,black" and brightred,black", both of which use the same 
"1,0" color codes. This probably increases ncurses memory usage. And it never 
caused any issues because nano only uses 8 of the 16 available colors. See 
attached patch.


> void set_colorpairs(void) {
>     const syntaxtype *sint;

Does "sint" mean something? Was it suppose to be "synt"?


> > Default foreground and background color is available as ",".
> >     color , "regex"
> >     set titlecolor ,  
> 
> To make the title bar indistinguishable from normal text doesn't seem
> very useful.

Just because it isn't useful to us doesn't mean someone else won't find it 
useful (there are many UI elements...). But i?color and all the UI colors share 
the same color parsing code, so they both get features needed by the other.


> But to be able to give back the normal color to text
> that has been unavoidably colored by earlier regexes, seems nice.

That is exactly how I've used it in several syntaxes. Especially useful for 
syntaxes that highlight everything at the top to catch errors, but then 
everything must be given a color, and too much color is bad.

remove-unneeded-bright-comparision.patch
Description: Text Data