In the beginning, the goal for nano was to be a drop-in replacement for
Pico. Pico did not know a Suspend command, so the ^Z keystroke needed
to be conditionalized on an option (-z or --suspend or the toggle M-Z),
just like the ^S and ^Q keystrokes (for stopping and resuming terminal
output) were conditionalized on --preserve.
But nano has abandoned full Pico compatibility since version 4.0. It
is time to unconditionalize ^Z as well. This should not be a problem:
Debian and Ubuntu have had 'set suspend' in their /etc/nanorc for years,
so a considerable portion of nano users have had ^Z enabled by default
for a long time, and no one seems to have complained.
If the keystroke bothers some user, they can unbind it in their nanorc.
They will still be able to suspend nano through the Execute menu: ^T^Z.
This addresses https://savannah.gnu.org/bugs/?61372.
The spotlighting should only be dropped when in the main menu, like in
the code thirty lines up, where 'timed' became TRUE only for MMAIN.
This fixes https://savannah.gnu.org/bugs/?61398.
Bug existed since version 5.8, commit 3f340836.
Normally, returning to the main loop will set 'focusing' back to TRUE,
but the replacement loop doesn't return until replacing is finished.
This fixes https://savannah.gnu.org/bugs/?61397.
Bug existed since version 5.0, commit d8249917.
When --breaklonglines is in effect and the user pasted just a few words
(anything without a linebreak), then act as if this short text had been
typed by the user and hard-wrap the line when it became overlong.
This fulfills https://savannah.gnu.org/bugs/?61353.
When --wordbounds (-W) is active, nano considers punctuation as
word-forming characters and will thus count words the same way
as 'wc -w' does. This is how nano counted words until now.
But when --wordbounds is not active (the default), only letters
and digits will be considered word-forming and thus lone groups
of lines and dashes and other punctuation will not be counted
as words, which is more like how a human would count words.
This addresses https://savannah.gnu.org/bugs/?61367.
(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.
