Re: [Nano-devel] patch #9772: Add color name definition to the nanorc configuration (color schemes)

[Justin F]

On Tue, 14 May 2019, Benno Schulenberg wrote:

> 
> Thanks for posting to devel.  This is the place to discuss big changes.
> 
> Op 13-05-19 om 19:31 schreef Justin F:
> > I posted a patch up at Savannah for your consideration:
> > 
> >   https://savannah.gnu.org/patch/?9772
> > 
> > Rationale:
> > 
> > Syntax definitions include color definitions for the highlights they
> > perform. Each matching color definition in the syntax must currently
> > specify a color pair which will be used for the sequences that match.
> > This means that either users accept the default syntax coloring, or
> > they copy the syntax definition and change the colors themselves.
> > 
> > This is a tedious and frustrating process for users, and whilst it is
> > a one-time activity, it does result in configurations that become
> > static whilst the system provided definitions may change and be
> > improved.>
> > Change interface:
> >
> > This change introduces a new command `defcolor` which takes a name,
> > and a color specification. The names can be used in place of the
> > fgcolor,bgcolor specifications in the `color` and `icolor` commands,
> > and will be replaced with the defined colors. This is done repeatedly
> > so that the color specifications may refer to other color names.
> 
> The indirection that you propose is interesting, but... brings more
> complication than the problem it solves is worth, in my opinion.
> 
> Your system would be most useful to people who want comments always
> to be the same color no matter in what type of file, and similarly
> for keywords and strings etcetera.  But I like that I can see from
> the colors used in the file what type of file it is: red comments,
> green strings -> Python; cyan comments, yellow strings, blue keywords
> -> shell; blue comments, yellow keywords -> C, and so on.
> 
> You're proposing that the syntaxes included with nano get changed to
> use defined colornames instead of the basic color names.  Let's see
> what that would do for the first color rule in sh.nanorc:
>
>   # Function declarations.
>   color brightgreen "^[A-Za-z0-9_-]+\(\)"
> 
> Would become:
> 
>   defcolor declaration brightgreen
> 
>   # Function declarations.
>   color declaration "^[A-Za-z0-9_-]+\(\)"
> 
> The rest of the file would require seven more defcolor commands, for
> keyword, option, command, variable, comment, string, and trailingspace.
> 
> But in fact all these colornames need to be prefixed with sh., as
> you propose, because otherwise changing a defined colorname would
> change the color in all the syntaxes, and I think few people would
> want that.

I would be inclined to say that users are more in favour of consistency in 
a user interface, and therefore having the same colours for the same types 
of data would be desireable. However, that's biased by my own expectation 
that that's sane, and I suspect that you probably know your users better 
than I :-)

It is because the colours are inconsistent, and because I do think that 
some people would want to have the flexibility for an individual syntax 
to have different colours, that I proposed the separation of the naming. 

> So, if the user wants to change the color of the comments in a shell
> script from the default cyan to green, they could do at the end of
> their ~/.nanorc:
> 
>   defcolor sh.comment green

Yes, and if they wanted them consistently coloured:

defcolor comment green
defcolor sh.comment comment

This is a better solution (to my mind) than the current situation where, 
if you don't like the colour scheme forced on you by the supplied 
syntaxes, you have to copy those syntaxes. Yes, it's a bit of a faff to 
write out these rules, but it's better than to have your syntax 
definitions drift from those used by the ones supplied by Nano. I 
certainly know that my own definitions are significantly different from 
those supplied with Nano either to fix deficiencies, or to set up the 
colours consistently.

> Hmm...  If only /etc/nanorc didn't exist, if only there were just one
> nanorc file (the user's own ~/.nanorc), then your whole system of first
> reading and storing all the color rules wouldn't be needed: one could
> stipulate that any modifying defcolor command must be issued /before/
> the relevant syntax file is included. (In this case of course the first
> defcolor wins, a later defcolor with the same colorname is ignored.)

<smile> Yes; we're working within a system that already exists.

> Anyway... I think your system is too much complication for too little
> gain.  Plus: it would make things slower, and we're trying instead to

All feature change makes things slower, but I wouldn't consider this to be 
too relevant to the editor itself. The impact is only on syntax parsing, 
and only performs lookups based on names, rather than using regular 
expressions - the much more time complex part of the system involves the 
regexes during rendering, which will outstrip the impact of this by 
orders of magnitude. I can certainly improve the performance by using 
some alternative structures to hold the data - hash, tree, whatever -
although it wasn't an area I was as concerned by when looking at it.

> make things faster, like by delaying the full parsing of syntax files.
> See https://savannah.gnu.org/bugs/?54928.  First that patch set will
> go in, and it will most likely break your patch completely.

Seems like that would be a significant change to the way that the syntax 
files are handled, but the principle functionality of my change look like 
they'd still be applyable within the scheme. Probably not a difficult 
thing to merge in, so I'm not that worried about doing that merge.

Personally, I am a little surprised that centi-second differences in 
startup time are of concern to users for that change, and architectural 
work is often important for the sanity of maintainers, and in making 
other things easier in the future :-)

However, if this change isn't viewed as giving enough gain, that's not a 
problem for me - I can continue using my own copies of the syntaxes files, 
and I'm no worse off, but I hoped that others might appreciate the ability 
to separate the colouring from the syntax. Thanks for your time and 
comments; I may try to update the patch once the optimisation change is 
applied, as that may make it useful in the future.

-- 
Charles Justin Ferguson
[ All information, speculation, opinion or data within, or attached to,
  this email is private and confidential. Such content may not be
  disclosed to third parties, or a public forum, without explicit
  permission being granted. ]