[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Nano-devel] [PATCH] various color tweaks
From: |
Brand Huntsman |
Subject: |
Re: [Nano-devel] [PATCH] various color tweaks |
Date: |
Mon, 5 Mar 2018 17:20:22 -0700 |
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.