This change moves the code responsible for backup creation to a new,
separate function, backup_file(). This function returns a boolean
indicating whether saving the buffer should proceed or not.
Signed-off-by: Michalis Kokologiannakis <michalis@mpi-sws.org>
The escape-sequence codes for the different keypad keys are simply
the relevant ASCII code plus 0x40, so they are easy to translate.
Also, do not accept keypad keys with multiple modifiers (Shift+Alt,
Shift+Ctrl, Alt+Ctrl, Shift+Alt+Ctrl) -- report "Unknown sequence"
for those.
Until now, on an xterm, Shift plus any keypad key would say
"Unknown sequence", which is not useful. On other terminal
emulators (urxvt, Pantheon, LXTerminal), Shift plus a keypad
key already produces the relevant digit or symbol, so this
change harmonizes the behavior of the different emulators.
However, on a Linux console, Shift plus a keypad key moves
the cursor and selects the text that is passed over. And
holding Alt while pressing a keypad key does nothing at all.
For the operator keys on the numeric keypad (/, *, -, and +),
make both the Alt and the Ctrl modifier a no-op.
This fixes https://savannah.gnu.org/bugs/?58731.
Bug existed since version 2.9.3, commit e734488c.
The file-saving procedure that nano followed was not crash-safe
under ext4 (and perhaps other filesystems) when editing existing
files. Specifically, modifying an existing file could lead to data
loss, since a modified file is not replaced atomically on disk.
Using "-B" did not ensure crash-safety either since the backup might
not have persisted on disk when the writeout of the file started.
In addition, if I/O pressure filled up the remaining disk space
after an existing file is truncated during save, nano would not
be able to finish saving the file, which would remain truncated.
This change addresses these issues by making nano do the following:
1) Make a temporary backup of the file being written so that there
is no time window such that (a) an existing file is truncated, and
(b) the buffer corresponding to said file has not been flushed to
disk. Such time windows are dangerous because, under certain
circumstances, they can lead to data loss on some filesystems.
The backup is made by copying the original file, and a second
attempt to HOME is made in case that first copy fails.
2) Use fsync() so that, when the save finishes, it is certain
that the file has been successfully written to disk.
This addresses https://savannah.gnu.org/bugs/?58642.
Signed-off-by: Michalis Kokologiannakis <michalis@mpi-sws.org>
This allows pasting six hexadecimal digits after typing M-V
in order to enter a specific Unicode character.
This fixes https://savannah.gnu.org/bugs/?58730.
Bug existed since version 4.8, since bracketed pastes
were introduced in commit f705a967.
The codes from (for example) U+D800 to U+DFFF are invalid. If any
such invalid code is entered at the Unicode Input prompt, nano should
not act as if the code was accepted and inserted into the buffer, and
should certainly not mark the buffer as Modified.
This fixes https://savannah.gnu.org/bugs/?58714.
Bug existed since version 4.9, commit b3faf353.
There is no need to place the cursor up front, as the drawing of
each name includes the coordinates where the name must be drawn.
Also, trim two comments and reshuffle a free().
When using --constantshow and --nohelp and opening a new buffer,
the cursor location should be shown on the status bar right away.
Bug existed since commit 2e688640 from a few hours ago.
The constant cursor display must be suppressed whenever a message
was printed to the status bar. That is: whenever 'lastmessage' is
something other than 'VACUUM'.
By default, this function is bound to ^L, to make that keystroke do
something actually useful. To not lose the Refresh function that this
keystroke had, the centering function additionally does a full redraw
and refresh of the screen.
The Haiku recipe seems to detect a .git directory somewhere, even though
they are building from a tarball. So, check instead for the presence of
nano's release script, which ought to be present only in a git checkout,
not in a released tarball.
Before version 2.9.8, nano would consider any line that started with
leading whitespace as the beginning of a new paragraph, and would thus
be unable to justify an indented piece of text (unless autoindent was
switched on). I thought that this was too limiting and changed the
way nano detects and parses paragraphs. It works fine in texts where
paragraphs occupy multiple lines, but breaks down for paragraphs of
a single line: nano merges those with adjoining lines.
Now, when -O or --bookstyle or 'set bookstyle' is used, nano will again
consider a line that begins with whitespace as the start of a paragraph
-- when 'autoindent' is OFF.
This addresses https://savannah.gnu.org/bugs/?57402.
Indirectly-reported-by: Sébastien Desreux <seb@h-k.fr>
Also-reported-by: Bill Kendrick <nbs@sonic.net>
Benno Schulenberg