nano-devel
[Top][All Lists]
Advanced

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

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


From: Benno Schulenberg
Subject: Re: [Nano-devel] [PATCH] various color tweaks
Date: Wed, 7 Mar 2018 17:57:46 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0

Op 06-03-18 om 01:20 schreef Brand Huntsman:
> ABI 6 allows more than 256 pairs but only if a new API is used. [...]

No need to go there.  Because, as said before: how many syntactic categories
does it make sense to distinguish by color?  And: how many colors can people
clearly distinguish (or confidently see as the same) when they are a few words
or lines apart.  Probably something like twenty, maybe thirty, forty max.

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

In theory it should, to protect a user from himself.  But in practice...
See above.

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

Point taken.  Will change it later.  But "syntax"...  I don't like
it when several variables start with the same word.  And I hate it
when some variable name is a substring of another name.  So, I will
need to rename 'syntaxes' and 'syntaxstr' first.

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

No, certainly not.  By far the most color pairs only specify a foreground
color, because that is what you want in a syntax: a single background color,
the default, because otherwise the display turns into chaos.

> Background is assumed to be normal?

Yes.

> Foreground and background are assumed to be normal if only attributes are 
> given?

Yes.

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

Yes.  It would be allowed to use a lone comma to mean default foreground
and background.  But it would be far clearer to use "normal".

Benno

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

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