patchGNU nano - Patches: patch #9772, adding color schemes (color name...

 
 

You are not allowed to post comments on this tracker with your current authentication level.

patch #9772: adding color schemes (color name definitions) to the nanorc syntaxes

Submitter:  Charles Ferguson <gerph>
Submitted:  Sat 16 Mar 2019 05:25:21 PM UTC
   
 
Priority:  3 - Low Status:  Wont Do
Privacy:  Public Assigned to:  None
Open/Closed:  Closed Release:  None

Tue 16 Jun 2020 11:35:34 AM UTC, comment #2: 
Benno Schulenberg <bens>
Group administrator
Mon 13 May 2019 10:50:59 PM UTC, comment #1: 

I haven't read your patch yet and only skimmed the post. I will fully read them after I redo another patch Benno is waiting on.

I've attached an unfinished patch I wrote a while back to do the same thing. It was written for 3.2 (git checkout v3.2) and may or may not apply to newer releases. Maybe you can get some ideas from it to improve your patch, such as being backward compatible with existing syntaxes. The current style is nice for small custom syntaxes and should always be supported.

    setcolor <name> <color> -- global
    setcolor <syntax>:<name> <color> -- private
    color <color> ""
    color $<name> "" -- private or global
    color $$<name> "" -- private

Add the following to your nanorc:

    setcolor type green
    setcolor keyword brightyellow
    setcolor number brightmagenta
    setcolor character brightmagenta
    setcolor string brightyellow
    setcolor comment brightblue
    setcolor reminder brightwhite,yellow
    setcolor eolspace ,green

I also wanted to allow disabling colors. Setting to "default" would uncolor something but disabling would eliminate the regex entirely. Syntaxes could be over-colored and users can choose what they want to be colored, without suffering a performance loss.

    setcolor <name> -
    setcolor <syntax>:<name> -

And also groups. Block and line comments would use "comment.block" and "comment.line" but "comment" can be used to set color for both of them. Keywords is another area this would be useful. Some users like them all the same color, others want some different colors or not colored at all.

You can use any of my ideas or code, as I don't know when I'll get around to finishing it.

(file #46901)

Brand Huntsman <brand>
Sat 16 Mar 2019 05:25:21 PM UTC, original submission:  

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 Ferguson <gerph>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attached Files

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by bens (Posted a comment)
  • -email is unavailable- added by brand (Updated the item)
  • -email is unavailable- added by gerph (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

     

    Follow 6 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2020-07-04 bens Open/ClosedOpen Closed
    2020-06-16 bens Priority5 - Normal 3 - Low
        StatusNone Wont Do
        SummaryAdd color name definition to the nanorc configuration (color schemes) adding color schemes (color name definitions) to the nanorc syntaxes
    2019-05-13 brand Attached File- Added syntax-color-variables.patch, #46901
    2019-03-16 gerph Attached File- Added 0001-Add-color-name-definition-to-the-nanorc-configuratio.patch, #46559

    Back to the top

    Powered by Savane 3.13-4448.
    Corresponding source code