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

[Benno Schulenberg]

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.

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

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

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

Benno

signature.asc
Description: OpenPGP digital signature