When after reading a file we are not in curses mode, it means we have
read data from standard input, either from the keyboard or from a pipe.
In the latter case, we first need to reconnect standard input to the tty.
And in both cases, we then need to reenter curses mode before being able
to display the number of lines that were read (or an error message).
So, move the reconnecting code from scoop_stdin() to its own function,
and call this function from read_file() when needed.
This fixes https://savannah.gnu.org/bugs/?56310.
Bug existed since version 2.1.8 when reading from stdin was introduced.
The 'quiet' parameter is only used when opening a help-text tempfile
or a spell-checked tempfile, and these files necessarily exist, so
'quiet' will never be checked for them. But in the weird case that
the help-text tempfile could not be opened, it is not a problem that
"New File" gets printed to the status bar because nano will crash
shortly afterwards. And when the spell-checked tempfile could not
be opened, a "Not Found" message is appropriate, but nano will crash
in this case too.
Trying to append does not work on a fifo, and we'd like to be able to
open a fifo again. Also, the append test causes a close event for the
given file at the moment of opening it, which makes using 'inotify' for
waiting for this file to be closed useless.
Commit f8f90272 added the append test, but the original request
(https://lists.gnu.org/archive/html/info-nano/2009-05/msg00000.html
by Damien Joldersma) asked only for a warning when the user did not
have enough privileges to write to the file.
So, drop the append test and just check the access bits.
This fixes https://bugs.debian.org/583196
and fixes https://savannah.gnu.org/bugs/?29312.
The original requests (https://bugs.debian.org/551717 by Paul Wise,
and https://savannah.gnu.org/bugs/?45383 by Mike Frysinger) asked
only that specifying a directory instead of a file name should not
open a new buffer. But commit 98ffb642 excluded everything that was
not a normal file. This avoids a hang when the user accidentally
tries to open a pipe or a socket, but also prevents any user from
doing so on purpose. And opening a fifo can be useful when wanting
to handle sensitive data that shouldn't be stored on disk.
This prepares the fix for https://bugs.debian.org/583196.
Now you can have a look elsewhere in the buffer (and even delete
or paste stuff there) and when you return to the original line
and continue typing, any spillover from automatic hard-wrapping
will spill over onto the same line it spilled over to before.
You can even switch to a different buffer and return and continue
typing, and stuff will still spill over to the same line.
In the bargain, this gets rid of a bit of flag-resetting code
that was run for many keystrokes, in most cases needlessly.
This addresses https://savannah.gnu.org/bugs/?56189.
The lack of initialization caused a nasty bug on some targets (such as
ARMv7) which would make it so that ^S would just say "Cancelled".
While x86 (both 64 and 32 bits) seems to initialize 'response' to zero or
a positive number, ARM does not, and there is usually a negative value in
its place, which triggers the 'if (response < 0)' check and, as a result,
the code says "Cancelled".
This fixes https://savannah.gnu.org/bugs/?56023.
Reported-by: Devin Hussey <husseydevin@gmail.com>
Bug existed since version 4.0, commit 0f9d60a3.
Signed-off-by: Devin Hussey <husseydevin@gmail.com>
