The warning is wrong when the user has just saved a buffer under a
new name. And when --quickblank is used, the warning most likely
gets cleared off before it is seen, and the user would just hear
the beep and be left wondering what happened.
This avoids https://savannah.gnu.org/bugs/?49875.
This disallows entering a verbatim ^J (0x0A) when typing text or
search terms, and disallows a verbatim ^@ (0x00) when typing a
filename. Nano beeps when the disallowed code is attempted.
This addresses https://savannah.gnu.org/bugs/?49897.
Also at the yes-no prompt, a 0x0A byte should be displayed as a ^J
instead of splitting the prompt bar in two and spreading it over
two lines.
This fixes https://savannah.gnu.org/bugs/?49934.
After a call to the Formatter or the Alternate spell checker, the data
on the undo stack could refer to line positions that don't exist any
more -- the chance is small, but it is there. So... throw the whole
undo stack away, to prevent undoing things wrongly or even crashing.
(Changes made with the internal spell checker can be undone and redone
without a problem -- nano keeps full track of those. But the changes
made with a formatter or an external spell checker happen in another
process, so nano has no record of them.)
This fixes https://savannah.gnu.org/bugs/?49920.
When using an external spell checker or formatter, the line with
the cursor might become shorter, which might result in the stored
cursor position being beyond the end-of-line. So, when restoring
the x position, make sure to limit it to the length of the line.
This fixes https://savannah.gnu.org/bugs/?49923.
In path names and file names, 0x0A means an embedded newline and
should be shown as ^J, but in anything related to the file's data,
0x0A is an encoded NUL and should be displayed as ^@.
So... switch mode at the two main entry points into the "file system"
(reading in a file, and writing out a file), and also when drawing the
titlebar. Switch back to the default mode in the main loop.
This fixes https://savannah.gnu.org/bugs/?49893.
Decode 0x0A bytes to 0x00 when saving the search history, and encode
them again when reading the file back in, to prevent nano from hanging
or aborting when encountering 0x00 on a line by itself.
After updating the color palette, the corresponding new window content
should be drawn immediately, before some other part of the code calls
doupdate(), to prevent the old content being shown in the new colors.
This fixes https://savannah.gnu.org/bugs/?49912.
Reported-by: Mike Frysinger <vapier@gentoo.org>
In nano 2.7.1 and 2.7.2, pressing Shift+Ctrl+Arrow on a Linux console
would behave as if Shift wasn't held. It got broken three months ago,
by commit 08cd197b, messing up the proper order of the checks.
This fixes https://savannah.gnu.org/bugs/?49906.
On some systems, typing ^C apparently results in a KEY_CANCEL in
the input stream, which gets hard-bound to the do_cancel function.
But in the main menu there is no Cancel function. So... in that
case, let it fall back to the plain old Ctrl-C code: 0x03.
Reported-by: Liam Gretton <liam.gretton@leicester.ac.uk>
A filename might contain spaces, so we can't look for the numbers
(the second and third elements) starting from the head of the line
-- we have to start at the tail and work backward.
This fixes https://savannah.gnu.org/bugs/?49879.
So they will not break a line in the positionlog file in two.
(Strangely, the reading in of such a log file already decodes
nulls back into newlines.)
This fixes https://savannah.gnu.org/bugs/?49877.
The byte 0x0A means 0x00 *only* when it is found in nano's internal
representation of a file's data, not when it occurs in a file name.
This fixes the second part of https://savannah.gnu.org/bugs/?49867.
Most full paths are needed only temporarily and will be freed within
milliseconds. Only 'full_operating_dir' and 'backup_dir' continue to
exist for the whole current session. Any partition, too, will soon be
unpartitioned, so the extra reallocation is just a waste of time.
Benno Schulenberg