The names of the authors were retrieved from:
git log -p --follow syntax/<name>.nanorc
and from:
git log -p --follow --all -- doc/nanorc.sample
For some files the original author is unclear, or
the file is/was too small to mention an author for.
The typo prevented several keywords from getting colorized.
This addresses https://savannah.gnu.org/patch/?10459.
Bug existed since version 2.1.6, commit 513157df,
since the Fortran syntax was introduced.
Stop doing colon parsing by default, to avoid surprises and frustration
for users that have filenames that end in a colon plus digits.
The equivalent rcfile option is, of course, 'set colonparsing'.
Using +1, or similar, before the filename disables any colon parsing
and the filename is taken as is.
When opening a nonexistent file with nano, it likely consists of only a
name without any path component, and thus without any slash. So when a
file regex checks for a slash, it should check also for start-of-string.
This fixes https://savannah.gnu.org/bugs/?65591.
Problem existed for the Makefile since version 2.9.8, commit 22663f8a,
and for .profile since version 3.0, commit 4a268678 (but earlier, nano
did not recognize .profile files at all).
This avoids miscolorizing part of a string when it contains a URL.
This fixes https://savannah.gnu.org/bugs/?64340.
Reported-by: Yonut Smith <deanlast3@gmail.com>
Problem has existed for more than twenty years, at least since support
for multine-line regexes was added in commit 6c1e6612 in 2002.
Use lightgrey for the prolog tags, as they normally are unimportant
boiler-plate stuff. Comments are likely to be more relevant.
Any /> is part of the tag itself, not of the attributes.
The file contained two syntaxes (each of them fairly large) that are
useful only for Gentoo users. I don't think the file should have been
distributed with nano ever, as the syntaxes are just a dead weight for
the users of all other distributions.
That is: colorize text after a blank-plus-hash as a comment when there
is at least one non-hexadecimal character among the first three.
This relaxes the demand that a trailing comment should have a blank
after the hash too, as implemented by commit 90946c5e two weeks ago.
Make types a bluish green, for more contrast with strings, so that the
latter can be made greener, for more contrast with the yellow keywords.
Make the main keywords bluer and less bright, and unbold and soften the
yellow ones. Soften the comments too.
Reference for case-insensitivity:
https://www.postgresql.org/docs/14/sql-syntax-lexical.html#SQL-SYNTAX-IDENTIFIERS
Also, colorize comments more readably (on a dark background), and
schemas less yelling, and languages more distinct from keywords.
And add a few more keywords, like IS and NULL.
Also, combine some keywords that can only occur together.
And drop a few that are probably rare, like LARGE OBJECT.
Reference:
https://www.postgresql.org/docs/14/bookindex.html
And use a more readable color -- blue is too dark on a black base.
Regular expressions in SQL are not written between // or %r{},
strings are not written between <> or %Q{} or anything similar,
and comments do not start with # -- and officially not with //
either, but some dialects seem to allow it.
This fixes https://savannah.gnu.org/bugs/?61381.
Bug existed since version 2.4.2, since the SQL syntax was included.
The path after 'include' is not a regex and does not need to be quoted;
when it's unquoted, colorize it specially, instead of leaving it red.
The syntax name after 'extendsyntax' should be brightgreen, like after
'syntax', but it's better that the subsequent commands have their own
special color.
Benno Schulenberg