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

[Brand Huntsman]

On Mon, 5 Mar 2018 20:23:26 +0100
Benno Schulenberg <address@hidden> wrote:

> > And it never caused any issues because nano only uses 8 of the 16
> > available colors.  
> 
> That last sentence I don't understand.

There are 16 colors from 0-15. 16 foreground colors times 16 background colors 
is 256 possible combinations. So ncurses uses an 8bit value to store a color 
pair index. A_COLOR is the mask of that 8bit region in the 32bit value. 
Technically there are 17 colors when default color is enabled, so 289 
combinations. But nano only uses 8+1 (0-7 and default), so 81 combinations. By 
creating a duplicate color pair (when comparing bright) you double the 
foreground colors to 16+1 times 8+1 background colors. But 153 pairs is below 
the 255 limit and no one could ever have triggered any issues.

ABI 6 allows more than 256 pairs but only if a new API is used. But all 
wattron/off calls would need to be replaced with wattr_on/off, and attributes 
would need to be stored separate from color pair in colortype.

I think the RGB code should limit a syntax to 255 pairs minus any used by the 
UI. Most syntaxes currently use about 20 max. Anyone have a problem with this?


> >> void set_colorpairs(void) {
> >>     const syntaxtype *sint;  
> > 
> > Does "sint" mean something? Was it suppose to be "synt"?  
> 
> They sound the same to me, and as "sint" is a bit strange, this makes
> it a strong and memorable variable to me.  But... now that I look at
> it again, maybe some people could think that it stands for "signed
> integer"?

Ya, a signed int with an -> looks bad in code. The syntaxtype field in 
openfilestruct is called "syntax", variables should also call it that. It is 
harder to contribute when everything has cryptic names, too much time wasted 
figuring out what something is.


> >> But to be able to give back the normal color to text
> >> that has been unavoidably colored by earlier regexes, seems nice.  
> 
> Being able to do that, is good.  But using a bare comma to indicate
> that the default color should be used... doesn't look very nice.
> Maybe we should introduce the color name "normal"?

I thought about that, but it causes consistency issues. And the refactor to 
support attributes added the default fg,bg "," for free.

color red "..."
color ,red "..."
color bold "..."
color #fff: "..."

Do we require those to be changed to:

color red,normal "..."
color normal,red "..."
color bold,normal,normal "..."
color #fff:normal "..."

Or do we make exceptions for some cases but not others. Background is assumed 
to be normal? Foreground and background are assumed to be normal if only 
attributes are given? Allowing exceptions requires more code. Requiring normal 
everywhere could be done without more code but it makes syntaxes more verbose.

Nano has always assumed lack of a color name was default color, that should 
probably continue.