This makes nano more usable for users that are accustomed to the
near universal use of ^F for Find/Search in other programs.
To keep the bindings consistent, make ^B start a backward search,
and let M-F and M-B search for the next occurrence in the matching
direction.
At least some of the VTE-based terminals claim to be compatible with
xterm-25color (and set TERM to that value). But they really aren't:
they mishandle the focus-in and focus-out events, for example. So,
catch and discard the corresponding keycodes that nano shouldn't be
seeing at all.
This improves the fix for https://savannah.gnu.org/bugs/?64578.
When the red, green and blue components of a three-digit hex #RGB code
are equal and they aren't #000 for black or #FFF for white, map them to
xterm-256color's 24-level grayscale ranging from index 232 to 255.
This means that the 14 gray levels available in #RGB codes all map to
different tones, whereas previously they mapped to only the four gray
tones available in the 6x6x6 color cube.
Signed-off-by: Andy Koppe <andy.koppe@gmail.com>
Xfce Terminal sets TERM to xterm-256color even though it does not have
all the capabilities that an xterm has, leading it to misinterpret some
escape sequence and produce a spurious 0x24C key code.
Intercept this mistaken key code and tell the user what is wrong.
This mitigates https://savannah.gnu.org/bugs/?64578.
Reported-by: Lawrence R. Steeger
An ambiguous option like --back or --word would cause nano to spew
the entire help text. It should do the latter only when the user
explicitly requests it.
The short option '-?' was removed nine years ago in commit 43019189,
then restored six years later in 5bd92d4c, and then removed again two
months later in 743100fe due to getopt() returning '?' for options
that aren't recognized, preventing the use of '-?' as a valid option.
However, getopt() provides a way to check for unrecognized options
via the 'optopt' variable, which gets set only for invalid options.
Signed-off-by: Mateusz Kazimierczuk <mataha+savannah@protonmail.com>
Signed-off-by: Benno Schulenberg <bensberg@telfort.nl>
When the directory that the user is browsing in is deleted by another
process at the moment that nano is building the list of file names,
this can result in an empty list, which some items in the main loop
in browse() cannot handle. Prevent this mishandling by not entering
the loop when the list is empty.
This fixes https://savannah.gnu.org/bugs/?64465.
Reported-by: Jerry Meng <jerrytstng@gmail.com>
Speller, linter, formatter, and execute-a-command cannot be used in
restricted mode, but the relevant keys should report that the function
is *disabled*, not that the key is unbound.
This fixes https://savannah.gnu.org/bugs/?64226.
Problem existed since version 3.2, since nano reads the nanorc files
also in restricted mode.
With some imagination, the lack of access could be inferred from the
other descriptions, but it's much better to be clear and explicit.
Also, separate two items that are unrelated and reshuffle them into
a neater order.
Triggered by https://savannah.gnu.org/bugs/?64181.
This seems to be the convention. For an example, see `man tar`.
This addresses https://savannah.gnu.org/bugs/?64125.
Reported-by: Eric S. Raymond <esr@thyrsus.com>
This suppression prevents the filename flashing by at the bottom
of the screen when switching between buffers.
This addresses https://savannah.gnu.org/bugs/?64019
Reported-by: Alan Cristhian Ruiz <alancristhian@protonmail.com>
Problem existed since version 6.0, since --zero was introduced.
Various tools will output filenames with line numbers in the format
<filename>:<line>:<column>. Support this format in addition to the
+<line>,<column> format when opening files.
Signed-off-by: Benjamin Valentin <benpicco@googlemail.com>
Signed-off-by: Benno Schulenberg <bensberg@telfort.nl>
The isxxxxx() functions expect their parameter to be either EOF or
a value in the unsigned char range. Passing a negative char value
could (in theory) result in unexpected behavior.
In view mode it should be impossible to modify any buffer, but...
when (through some bug) the user did succeed in modifying a buffer,
this should not lead to writing out this modified buffer to disk.
Had this safety stop been present earlier, it would have prevented
the second part of https://savannah.gnu.org/bugs/?63616.
A string bind can only contain bytes (chars), not keycodes (integers,
in nano upto 0x4FF). So, apart from an error code or a placeholder
command code, get_code_from_plantation() can only return a byte.
The function get_code_from_plantation() should return ERR only when
the string bind is fully exhausted. In the normal case, where some
bytes are still available, it should return the first of these bytes,
so that the {verbatim} function will work too.
This fixes https://savannah.gnu.org/bugs/?63702.
Bug existed since version 7.0, commit 958ec294,
since command cartouches were introduced.
This separation avoids the impression that we're thanking the mentioned
people for their use of nano (something they probably don't do).
(Also, remove two other blank lines -- effectively moving these two
lines further up, keeping the total amount of whitespace the same.)
