(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.
Or rather, move the chapter about command-line options to between
the chapters on file browser and feature toggles. Also, rename the
chapter about the built-in help, and move the section about screen
layout to be the first in the editor-basics chapter.
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.
Texinfo-6.8 (that was used to build the docs of nano-5.9) changed
the way the @contents command is processed for HTML output, with as
result a detailed table of contents at the start of the HTML page.
That is ugly and too much detail. To avoid that, produce a table
of contents only when generating output meant for printing.
This fixes https://savannah.gnu.org/bugs/?61344.
Bug existed since version 5.9.
What @* does is guesswork when you don't use Texinfo regularly.
That the "sp" in the @sp command refers to vertical space is not
very clear either, but the command is used on nearby lines too,
so better use it more.
Also, improve two wordings and fix a four-year old typo.
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
In olden times, each help text started with a title line in the text
window followed by a blank line. But since version 2.8.2, since the
help texts have become almost regular buffers (and thus searchable),
the title of the help text is in the title bar, and since version 4.0,
since --morespace became the default, the text will start immediately
below it. But a title line immediately followed by text, without a
blank line between them, does not look nice. So, add such a blank
line back when not using --emptyline (and also when using --minibar,
because the top of the terminal window is like a title bar).
When the history file has been created by nano, it will not contain
any duplicate search or replace strings, nor duplicate commands, so
checking for such a duplicate for each read item was a waste of time.
And if the user edited the history file and created duplicates, who
are we to filter them out? They will not cause the history mechanism
to malfunction; they just take a little extra memory.
(Aaah, being able to define a keyboard macro
came in very handy when making this edit.)
This fixes https://savannah.gnu.org/bugs/?61331.
Bug existed since before version 2.2.0.
If all is programmed well, then the functions 'get_older_item' and
'get_newer_item' will only occur when a history list is passed to
acquire_an_answer(). But let's keep it certain we don't dereference
a NULL pointer.
When the user immediately cancels a search (^W^C), then nothing in
the history stack has changed, so then there is no need to reset the
history pointer to the bottom.
This slightly improves the fix for https://savannah.gnu.org/bugs/?61316.
This also gets rid of an assignment in an 'if' clause (twice),
elides a local variable, and makes it clearer that a pointer
gets moved to the previous or next item (instead of hiding it
as a side effect of the function call).
Benno Schulenberg