In many places a carriage return is not valid whitespace and should
thus not be colored as such. In some of these places a vertical tab
or form feed is maybe valid whitespace, but it would be ugly or even
wrong to color them because they are not part of the subsequent
comment or keyword.
This fixes https://savannah.gnu.org/bugs/?60456.
Changes:
1. There may be zero spaces between 'include' and '<...>'.
2. Blanks and '=' may occur inside '<...>' but '>' may not.
3. There must be at least one character inside '<...>'.
References:
Change 1:
C: www.open-std.org/jtc1/sc22/wg14/www/docs/n2310.pdf#subsection.6.10.2
C++: www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/n4659.pdf#section.19.2
Changes 2 and 3:
C: www.open-std.org/jtc1/sc22/wg14/www/docs/n2310.pdf#subsection.6.4.7
C++: www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/n4659.pdf#section.5.8
Signed-off-by: Hussam al-Homsi <sawuare@gmail.com>
Labels may contain digits (after the first character).
And the colon after "default" should not be colored.
Inspired-by: Hussam al-Homsi <sawuare@gmail.com>
Now that a search match gets highlighted, the unsuspecting user might
think that the text is selected, because it is colorized the same way
as selected text. Avoid this by colorizing a highlighted search match
with its own specific color, black on yellow by default.
This fixes https://savannah.gnu.org/bugs/?59769.
Reported-by: Tiago Almeida <tjamadeira@gmail.com>
Bug existed since version 5.0, since --bookstyle was introduced.
For some reason the Romanian PO file contains a literal ^Q in one
of its translated messages -- currently at line 1984. This stray
^Q causes 'file' to classify po/ro.po as data.
Make such mistaken control codes easier to spot when using nano.
Constants that consist of a single character are valid too.
And a lone hash character on a line by itself also.
Signed-off-by: Hussam al-Homsi <sawuare@gmail.com>
Signed-off-by: Benno Schulenberg <bensberg@telfort.nl>
And mention that a background color does not work on libvte before 0.55.
To find out the version of libvte on your system:
ls -R1 /usr/lib | grep libvte | grep 00 | grep -o "0\..."
The user had better avoid using the keystroke in a macro, but
when typing directly at a responsive machine there is no problem,
M-[ is a perfectly valid and recognizable keystroke.
This fulfills https://savannah.gnu.org/bugs/?58820.
A forward slash does not need to be escaped, and the backslash itself
should not be escaped: it serves to escape the star, to make it literal.
Also, remove a stray end-of-line anchor ($).
The modifier has to come before the foreground color name, separated
by a comma, and after 'bold,' (when present). This has no effect on
terminals that are incapable of cursive text, like the Linux console.
This fulfills https://savannah.gnu.org/bugs/?56525.
After a year or so, when people have had time to convert their syntaxes
to use 'bold' and/or 'light' instead of 'bright', we can drop this
colorizing, and still later stop recognizing 'bright' altogether.
The name 'bright' does not fit its effect (often bolding the typeface),
so better discourage its use.
Furthermore, colorize 'bold' and 'light' also for interface colors.
This makes it possible to avoid the misnamed prefix "bright". It is
misnamed because (on current terminal emulators, when the brightening
of bold is switched off) it just makes the typeface bold, not the color
brighter. The prefix "light" will now only make the color brigther,
and the modifier "bold" will just make the typeface bold (on terminal
emulators, when the brightening of bold is switched off).
On a Linux console, which is not capable of bolding the typeface,
"bold" will brighten the color.
This fully fulfills https://savannah.gnu.org/bugs/?58503.
The prefix "bright" will continue to make the color brighter AND/OR
make the typeface bold (depending on how the terminal is configured
and on its capabilities), but the prefix "light" will just make the
color brighter (if the terminal can do that).
The prefix "bright" continues to do the same as what it did before,
to not change the appearance of user-defined syntaxes. And having
an option to change the meaning of "bright"... would be confusing.
This partially fulfills https://savannah.gnu.org/bugs/?58503.
Benno Schulenberg