[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH] rcfile: support "#rgb" format for specifying colors in 256-c
Re: [PATCH] rcfile: support "#rgb" format for specifying colors in 256-color terminals
Tue, 16 Nov 2021 11:23:13 +0100
Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.13.0
Op 15-11-2021 om 18:58 schreef Brad Town:
> This fulfills https://savannah.gnu.org/bugs/?56445.
Thanks! Nice and clean and simple.
> +/* Return the index of the color that is closest to the given RGB levels,
> + * assuming that the terminal uses the 6x6x6 color cube of xterm-256color. */
> +short closest_index_color(short r, short g, short b)
> + if (COLORS != 256)
> + return THE_DEFAULT;
Somehow the whitespace in your patch is mangled. A properly indented
patch is here:
For the curious, the history of the patch is here:
To prevent these new color codes from getting colorized as comments,
I propose to make the following change to the nanorc.nanorc syntax:
-color brightblue "(^|[[:blank:]]+)#.*"
+color brightblue "^[[:blank:]]*#.*|[[:blank:]]#[[:blank:]].*"
This requires that in a trailing comment the # be followed by a blank,
but I think this is an acceptable restriction, because in fact nano
does not really support trailing comments. Trailing comments are
possible on commands like 'set' and 'bind' because nano stops reading
those lines as soon as a command is complete, meaning that the user
can put anything on the rest of the line, with or without a #. The
nanorc.nanorc will color things after " #" blue, but that is just for
esthetics, and it is incorrect after 'color' commands, which allow
only regexes after them and nothing else. Maybe nano should be more
strict and check that, if end-of-line has not been reached after a
command is complete, that the first non-blank character is a hash
followed by a blank?
Description: OpenPGP digital signature