The terminal in VSCode splits pastes into 50-byte chunks and can
thus split an escape sequence somewhere in the middle, resulting
in nano failing to recognize the end-of-bracketed-paste sequence
and thus hanging -- until another, different-sized paste is made.
Avoid this hang by interpreting any invalid escape sequence that
starts with "\e [ 2" as a truncated end-of-bracketed-paste.
(This will leave a spurious tilde after the 39-character paste,
which is not nice but... better than hanging.)
This works around https://savannah.gnu.org/bugs/?64996.
Reported-by: Jacob Lifshay <programmerjake@gmail.com>
Even though in nano the names F13 to F24 exist, these names actually
refer to Shift+F1...Shift+F12. One cannot blame people for thinking
that F13 in nano is the same as F13 in Xorg, so... recognize the escape
sequence for the latter and map it to what nano calls F13.
This accommodates users that put F13...F16 in a custom keymap for Xorg.
This fixes https://savannah.gnu.org/bugs/?64632.
Reported-by: Danny Milosavljevic <dannym@scratchpost.org>
Problem existed since version 5.0, commit 9a6158cd.
When softwrapping at blanks, the wrapping routine should, when called
again, continue searching from where the previous chunk ended, not from
the point it reached during that previous search, because this could be
*just* beyond the space that could be the next breaking point.
This fixes https://savannah.gnu.org/bugs/?64945.
Reported-by: Andreas Schamanek <schamane@fam.tuwien.ac.at>
Bug existed since version 6.4, commit 0e9bef34.
When the user hits the M-C toggle while option --zero is in effect,
instead of complaining "Not possible", do what the user probably
tries to achieve: cancel `zero` mode and switch on `constantshow`.
This makes nano more usable for users that are accustomed to the
near universal use of ^F for Find/Search in other programs, and
especially for users that somehow access a terminal through their
browser (where ^W will, destructively, close the terminal tab).
(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.)
Suggested-by: Chris Allegretta <chrisa@asty.org>
Suggested-by: Donnie Ferris <DonnyBahama@gmx.com>
https://lists.gnu.org/archive/html/nano-devel/2023-01/msg00001.html
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.
