[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Nano-devel] streamlining a bit of syntax coloring
From: |
Benno Schulenberg |
Subject: |
Re: [Nano-devel] streamlining a bit of syntax coloring |
Date: |
Sun, 17 Jul 2016 20:01:12 +0200 |
On Sun, Jul 17, 2016, at 16:07, Rishabh Dave wrote:
> Signed patch is attached. It was kind of difficult to write commit
> message mostly due to my understanding of the changes.
Well, if you don't understand the purpose, you shouldn't write
the patch.
> I am curious regarding the addition of a variable to colortype: can't
> we replace the instances of variable attributes by the expression
> initializing attributes; i.e. -
>
> wattron(edit, (bright) ? (COLOR_PAIR(varnish->pairnum) | A_BOLD) :
> COLOR_PAIR(pairnum));
You're missing "varnish->" twice. And why not use the same order
as in the actual patch?:
wattron(edit, COLOR_PAIR(varnish->pairnum) |
(varnish->bright ? A_BOLD : A_NORMAL));
> wattroff(edit, (bright) ? (COLOR_PAIR(varnish->pairnum) | A_BOLD)
> : COLOR_PAIR(pairnum));
This could simply be:
wattroff(edit, COLOR_PAIR(varnish->pairnum) | A_BOLD);
There is no need to check whether A_BOLD is on or off; watroff()
just says that it has to be off.
> I know it is now just previous block of statements wrapped into a too
> long statement but it would save a variable which we use only a couple
> of times
We may use the variable in just two places, but it saves us doing
twice the COLOR_PAIR and once the '?' and twice the '|' for every
bit of color on the screen. Instead of doing that computation again
and again, hundreds of times as we scroll through a file, we can do
it just once up front, done. Don't compute during runtime what
you can prepare during compile time or during initialization.
True, it saves very little, maybe two hundred nanoseconds per
screen refresh, but I like it that way.
Benno
--
http://www.fastmail.com - Email service worth paying for. Try it for free