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

[Justin F]

Hiya,

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.

For example, given a C syntax definition like this:

syntax "c" "*.c"
color c.comment "//.*"
defcolor c.comment comment

Together with a standard definition of colors such as:

defcolor comment green

The default coloring of the C comments would then be green. Should the
user wish to override this color, they would merely update their user
nanorc file with:

defcolor comment brightblue

If they wanted to /only/ change the C comments, leaving other syntaxes
alone, they could use:

defcolor c.comment brightblue

The use of period to separate a syntax name from a name specification
is purely a convention used during the development of this feature -
any other format could be used, or the use of an indirect coloring
could be abandoned if it was seen to be excessive. The indirect
coloring mechanism makes sense where multiple syntaxes exist which
intend to use a common color scheme.

The most recent `defcolor` specification wins, which means that any
color definitions in the system nanorc files can be overridden by the
user easily.

Implementation:

The whole feature is behind the ENABLE_COLORNAMES define, configurable
through the `configure` script. It is enabled by default here. Because
the use of the color names would require nanorc files which are not
backward compatible, I chose to protect the feature by an option. The
feature is also more expensive in terms of memory usage whilst reading
the files, so in some environments users may wish to disable the
feature.

The `defcolor` command accumulates the color names that are defined in
a linked list. These color names are checked at definition time to
ensure that they only refer to names that exist - this should avoid
generating a color name that refers to itself, and make it easier to
spot typos by reporting errors early.

The `color` and `icolor` command have been changed to deal with the
new color names in a different way when the options are enabled.
Instead of generating colors (fg, bg, attributes at parse time), the
color name is recorded for later resolution. To record all the
information necessary, a new structure is added to the colortype
which holds the necessary information needed to report the file and
line should the resolution fail for any reason in the later
resolution stage.

The necessity for two stages is because otherwise colors chosed by
the user would be unable to override those that were previously
selected as the files were parsed. It is necessary to ensure that
everywhere that a given color name is used, the colors are updated.

The name of the function that performs the parsing of color names
and returning the colors is renamed to `resolve_color_names` (as it
isn't being used during the parse phase). The first thing that the
function does is to repeatedly replace the color names that were
supplied with those from the color names list generated by
`defcolor`.

Once all the nanorc files have been parsed, a new
`resolve_syntax_colors` function is used to step through all the
syntaxes that were defined, and all the colors within those
syntaxes and resolve the colors. The function restores the
context used by the error reporting system to ensure that any
issues at this stage are reported with the correct file and line.
Once the colornameref has been processed, it is freed - the memory
usage is only during the nanorc parsing.

Multiple colortype uses may refer to the same colornameref (for those
cases where multiple regexs are supplied on a `color` command), so
the structure also includes a reference count to ensure that they
are only freed when the last usage of the colornameref has been
handled.

Within this change, no nanorc files are updated to use the color
naming. 
----

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