[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
signature.asc
Description: OpenPGP digital signature