When a help-text buffer is closed while exiting from the help viewer,
the rest of the exit code takes care that the preceding buffer gets
displayed properly. And when a help-text buffer is closed because a
SIGWINCH occurred, doing anything for the preceding buffer is a waste
of time because a new help-text buffer will be opened and displayed
instantly.
This avoids the substantial overhead of first writing and then reading a
temporary file, and in the bargain removes two possible failure points.
This fulfills https://savannah.gnu.org/bugs/?56371.
Closing a buffer automatically switches to the next buffer. But for
the help-text buffer this is not the desired behavior, so each closing
needs to be followed by a switch to the preceding buffer.
This fixes https://savannah.gnu.org/bugs/?56411.
The previous commit makes that the terminal's state is only resaved
when standard input is actually reconnected to the terminal, and
leaves it unchanged otherwise. Apparently this is enough to fix
https://savannah.gnu.org/bugs/?56394.
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.
For some reason a SIGWINCH or SIGINT "corrupts" the current state of
the terminal, and magically validates the state that was saved first.
This fixes https://savannah.gnu.org/bugs/?56394 properly.
The user will understand that changing the state of the terminal
while inputting data into nano is not the same as changing this
state before nano has started or after nano has exited.
This fixes https://savannah.gnu.org/bugs/?56394.
Bug existed since version 2.4.2.
Either this enabling is not needed at all when the original terminal
state has been restored, or it will be needed in the tiny version too.
Also condense some comments.
If the rest of nano is correct, then these checks are superfluous and
only slow the loops down. But if there is some incorrect code, then
let nano crash on dereferencing NULL so we can find and fix the bug.
No one ever reported seeing the message that was removed in commit
c039aaad one month ago, so most likely the code is correct and nano
never calls line_from_number() with a non-existent line number.
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.
For both an integrated and an external spell check, fake the Shift key
being held so that (when the cursor is moved by a changed length of a
word) a Shift-selected region is not unexpectedly cancelled.
This fixes https://savannah.gnu.org/bugs/?56365.
Don't bother checking for an error from sigaction(), because the only
things it could error out for is when it is passed an invalid signal
(which SIGINT isn't) or oldaction/newaction would point to memory that
is outside of nano's control (which is obviously not the case).
Also, the setup of signal handlers during startup does not check for
errors, so why do it here?
Use printf's ability to align things (instead of trying to do it
ourselves and failing when the tab size of the terminal is not 8.)
Suggested-by: Vincent Huisman <site.gentoobugzilla@dataghost.com>
This fixes https://savannah.gnu.org/bugs/?56372.
Reported-by: Vincent Huisman <site.gentoobugzilla@dataghost.com>
If functions deeper down would put up some message on the status bar,
it should not be cleared. The chance that messages from a spell-check
program stay onscreen is minute: the edit window is fully refreshed,
the status bar is fully drawn, and the help lines (if there are any)
are redrawn. Only the title bar is not refreshed, but the chance that
an error message has spilled onto the top row... And anyway, the
spell checker should not print any error messages at all.
Benno Schulenberg