(It would be much better if the build rules automatically included
any *.nanorc files in the syntax/ directory into the tarball...)
This fixes https://savannah.gnu.org/bugs/?61391.
Reported-by: John Prokos <jprokos@gmail.com>
Bug existed since version 5.9, commit c2790a8a.
Also, trim some whitespace and group one rule better.
Also, fix a stray closing parenthesis in the JSON syntax,
and add the missing slash to the possible escaped characters.
(Reference: https://www.json.org/json-en.html.)
Also, improve the ending of multiline strings in the Rust syntax.
A backslash should not be allowed inside a quoted string unless
it is used to escape another character.
This fixes https://savannah.gnu.org/bugs/?61389.
Bug existed since each of these syntaxes was introduced.
(Awk and Fortran do not know include files with names between
angled brackets, so those regexes are dropped in the bargain.)
Quoted strings cannot start within another quoted string and end after
that other string has ended. Therefore single-quoted and double-quoted
strings should (as much as possible) be colorized by a single rule, so
that overlapping colorations are avoided.
(This also fixes a double typo in the PHP syntax (\. --> \\.) that has
been there since the PHP syntax was added in 2008, commit 90ee8ee4.)
This fixes https://savannah.gnu.org/bugs/?61387.
Bug existed since each of these syntaxes was introduced,
the oldest ones around 2006, a few others around 2015.
The one that got it right was the Lua syntax from 2011.
The "\.?" part was pointless. It says that the string "nanorc"
*might* be preceded with a period. Sure, but if the period is
absent, then anything else may be there too, so the optional
period gives zero restriction.
The restriction should be: either the filename has the extension
".nanorc" OR the full filename is "nanorc". So the "nanorc" part
must be preceded by either a period or a slash.
(However, in the times of commits 3dc0e23e and dc9c40a5, fifteen
and eighteen years ago, it was still the user-provided filename
that was matched against the regex, not the full-path filename.
The latter method arrived in commit ec8d51be, six years ago.)
Strings may not contain a double quote unless it is escaped.
Reference:
https://doc.rust-lang.org/reference/tokens.html#string-literals
(This will still not colorize multi-line strings with an unescaped
newline, will still colorize "this\" as if it were a valid string,
and will still miscolor things when there is another string after
the closing quote of a two-line string. But those things can't
be helped -- line-based regexes cannot emulate a full parser.)
This fixes https://savannah.gnu.org/bugs/?61361.
Reported-by: Elias Jonsson <e@ejon.eu>
Bug existed since version 2.6.1, since the Rust syntax was introduced.
Within a bracket expression, the backslash is not special,
so it does not need to be escaped.
The double backslashes within brackets were found with:
grep -o '\[[^][]*\\\\[^][]*\]' syntax{,/extra}/*rc
Also, incorporate the square brackets into some bracket expressions
by listing the closing bracket first, saving a separate regex for
those two brackets.
An @command must either start at the beginning of the line and be
followed by whitespace or EOL, or it must be followed by a brace.
Colorizing just any "@text" string colored too much.
Also, allow an @} and another @command{} within a pair of braces,
colorize only the valid @-commands with uppercase in their names,
unbold enclosed command arguments, colorize the directory entries
for the manual, and properly colorize also the comments that use
the full @comment command.
Reference:
https://www.gnu.org/software/texinfo/manual/texinfo/html_node/Command-List.html
Testing was done with:
info texinfo @-C "Command List" --output=list
sed -i -e "s/^'//" -e "s/'$//" list
nano list -Ytexinfo
Some Yaml files use path names and sometimes version numbers as keys,
even though / and . are not officially in the character set allowed
for key names (just like underscore is not), as far as I understand.
Also, do not colorize any backslash escapes as invalid
because some of them occur sometimes in value strings.
Also, colorize only the valid double-exclamation tags.
Perl keys can contain a double colon. And unspaced colons occur
quite regularly in values (URLs, IPv6 addresses, and the like)
and should not be colored as if they were an error.
Removals:
- All eblits were dropped from Gentoo years ago.
- HDEPEND was never fully approved, superseded by BDEPEND.
- Keywords 'dohard' and 'dosed' have been banned since EAPI 4:
https://projects.gentoo.org/pms/5/pms.html#x1-130001r8
- Several arches are dead. For the currently supported list:
https://gitweb.gentoo.org/repo/gentoo.git/tree/profiles/arch.list
Additions:
- Two eapply functions replace the epatch functions, but epatch
is still supported until EAPI 6 is banned.
- Modern build systems (ninja and qmake5) have new functions.
- EAPI 7 added more builtins: dostrip, get_libdir, ver_*
- Highlight the cross-compiler boolean function. (There are too
many toolchain functions to add them all, but this one is very
common and has a long name, so highlighting it is useful for
catching typos early.)
The EAPI documentation:
https://projects.gentoo.org/pms/8/pms.html#x1-590007
An extensive write-up on EAPI 7:
https://mgorny.pl/articles/the-ultimate-guide-to-eapi-7.html
Signed-off-by: David Michael <fedora.dm0@gmail.com>
Add IDEPEND from EAPI 8, and also add more EAPI 7 roots so that all
of ROOT, EROOT, SYSROOT, ESYSROOT, and BROOT are supported.
Signed-off-by: David Michael <fedora.dm0@gmail.com>
In Dejavu Sans Mono the old pointing triangles had a decent size,
but in Noto Mono and in Ubuntu Mono (fonts that handle combining
diacritics better) those triangles were massive, visually taking
up more than a single cell, overlapping the closing parenthesis
when they are displayed in the second column. Not nice.
The new pointing small triangles look good in the Noto and Ubuntu
fonts, but are real tiny in Dejavu. :| Oh well, one can't have
everything.
(Other triangles are not an option, because they don't degrade to
actual arrows when on a Linux console.)
When it is not specified, it defaults to the value for 'titlecolor'.
When not using --minibar, I want the title bar to be blue (as that is
how I've always had it), but with --minibar, I want this mini bar to
be grey, as otherwise it reminds me too much of the prompt bar.
Also, colorize 'set minicolor' as valid in a nanorc file.
Instead of quoting M- as 'M-', some translations use «M-» (Catalan),
(M-) (Croat), "M-" (Italian), „M-” (Romanian), or „М-“ (Serbian).
Those occurrences of M- nor its quotation marks should be colored.
Achieve this by excluding those quotation marks from the M- regex,
and then colorizing M-) and M-" only when at start of line (first
column of shortcuts) or when between parentheses (second column).
Only the basic colors (like red, blue and yellow) can take the prefix
"light" or "bright", not the extra colors (like pink, lagoon and lime).
This fixes https://savannah.gnu.org/bugs/?60674.
Bug existed since version 5.0, since the extra colors were introduced.
The "^_" has always been poorly legible (the underscore melting into
the bottom of the terminal) and difficult to type (Shift+Ctrl+minus).
The "^/" is both more readable and easier to type.
In terminal emulators, "^/" is shown, but on a Linux console "^-",
as ^/ does a backspace in the default console key mapping.
Also, allow using "^-" when rebinding ^_ in a nanorc file.
This addresses https://savannah.gnu.org/bugs/?57393.
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.
Benno Schulenberg