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

[Benno Schulenberg]

Op 04-03-18 om 23:03 schreef Brand Huntsman:
> On Sun, 4 Mar 2018 11:53:50 +0100
> Benno Schulenberg <address@hidden> wrote:
>> 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.

My machines are low-end devices.  Nano runs fine on them.  (I make
sure to only load syntaxes that I use now then, not the entire array
that nano has available.  Not loading a bunch of syntaxes, and not
using libmagic, saves far more memory than trying to trim nano's
data structures.)  Don't get me wrong: I'm all for reducing nano's
memory footprint, but it is low on my list of priorities.

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

Yeah, I goofed there.  Sorry.

> It is good you brought it up though, why was nano comparing bright there?!?!

Don't know.  You're the color expert by now.  :)

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

That last sentence I don't understand.

> See attached patch.

I've tried the patch and can't see any adverse effects anywhere --
although I don't understand why.  :|  Pushed.  Thanks.

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

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

Benno

signature.asc
Description: OpenPGP digital signature