The spotlighting should only be dropped when in the main menu, like in
the code thirty lines up, where 'timed' became TRUE only for MMAIN.
This fixes https://savannah.gnu.org/bugs/?61398.
Bug existed since version 5.8, commit 3f340836.
Normally, returning to the main loop will set 'focusing' back to TRUE,
but the replacement loop doesn't return until replacing is finished.
This fixes https://savannah.gnu.org/bugs/?61397.
Bug existed since version 5.0, commit d8249917.
When --breaklonglines is in effect and the user pasted just a few words
(anything without a linebreak), then act as if this short text had been
typed by the user and hard-wrap the line when it became overlong.
This fulfills https://savannah.gnu.org/bugs/?61353.
When --wordbounds (-W) is active, nano considers punctuation as
word-forming characters and will thus count words the same way
as 'wc -w' does. This is how nano counted words until now.
But when --wordbounds is not active (the default), only letters
and digits will be considered word-forming and thus lone groups
of lines and dashes and other punctuation will not be counted
as words, which is more like how a human would count words.
This addresses https://savannah.gnu.org/bugs/?61367.
In olden times, each help text started with a title line in the text
window followed by a blank line. But since version 2.8.2, since the
help texts have become almost regular buffers (and thus searchable),
the title of the help text is in the title bar, and since version 4.0,
since --morespace became the default, the text will start immediately
below it. But a title line immediately followed by text, without a
blank line between them, does not look nice. So, add such a blank
line back when not using --emptyline (and also when using --minibar,
because the top of the terminal window is like a title bar).
When the history file has been created by nano, it will not contain
any duplicate search or replace strings, nor duplicate commands, so
checking for such a duplicate for each read item was a waste of time.
And if the user edited the history file and created duplicates, who
are we to filter them out? They will not cause the history mechanism
to malfunction; they just take a little extra memory.
(Aaah, being able to define a keyboard macro
came in very handy when making this edit.)
This fixes https://savannah.gnu.org/bugs/?61331.
Bug existed since before version 2.2.0.
If all is programmed well, then the functions 'get_older_item' and
'get_newer_item' will only occur when a history list is passed to
acquire_an_answer(). But let's keep it certain we don't dereference
a NULL pointer.
When the user immediately cancels a search (^W^C), then nothing in
the history stack has changed, so then there is no need to reset the
history pointer to the bottom.
This slightly improves the fix for https://savannah.gnu.org/bugs/?61316.
This also gets rid of an assignment in an 'if' clause (twice),
elides a local variable, and makes it clearer that a pointer
gets moved to the previous or next item (instead of hiding it
as a side effect of the function call).
Whenever invoking a search prompt, calling up historical search items
should start with the newest item.
This fixes https://savannah.gnu.org/bugs/?61316.
Bug existed since version 2.8.2, since help texts became searchable.
When the answer at the prompt was clear before the user went up into
the history list, the answer should be cleared again when the user
comes back down to the present.
This fixes https://savannah.gnu.org/bugs/?61308.
Bug existed since before version 2.2.0.
For consistency, these five names ought to start with "flip_", but
then the bindable functions would need to be renamed too, and that
would be annoying for the user, *and* it would create too many names
that start with "flip" -- it wouldn't be distinctive any more.
When the current filename is equal to the filename of the buffer,
then clear the filename, because the chances that the user wants
to append or prepend a file to itself are practically nil.
This fulfills https://savannah.gnu.org/bugs/?61243.
The keystrokes are not listed, but should work like
they do in a normal, editable buffer.
This fixes https://savannah.gnu.org/bugs/?61274.
Bug existed since version 4.0, commit bc98dbca.
The functions to_first_file() and to_last_file() can get called from
do_statusbar_input(), which is called indirectly from do_prompt(),
and are expected to make the corresponding adjustment.
This fixes https://savannah.gnu.org/bugs/?61273.
Bug existed since version 5.0, commit 07c1ac90.
This avoids an unused and misleading assignment that might make
someone think the incremented variable will be used again.
Signed-off-by: Hussam al-Homsi <sawuare@gmail.com>
The calls of write_file() in do_spell() and do_formatter() write out
a temporary file -- such a file does not have an 'openfile' record,
so setting 'annotate' to TRUE was pointless. Using the correct value
for this parameter allows dropping two conditions in write_file().
And when 'exiting' is TRUE and --save-on-exit is in effect, it is
slightly wasteful to stat() the written file and store the info in
its 'openfile' record as the buffer will be closed directly after.
So, now the only place where 'annotate' is TRUE is when writing out
the full buffer to a normally named file.
First, we don't want the writing of an emergency file to be interrupted
by the user. But more important: the routine for restoring the handler
also disables SIGINT, which would leave the terminal with a non-working
Ctrl+C.
Saving an emergency file calls write_file() in a unique manner: with
thefile == NULL, fullbuffer == FALSE (even though the entire buffer
will be saved, of course) and tmp == TRUE (even though it is not a
temporary file, as it will persist after nano exits). But in fact
we want the handler for Ctrl+C installed only for normal files, not
for temporary files and not for emergency files -- the user should
not be able to interrupt the writing of those.
This fixes https://savannah.gnu.org/bugs/?61237.
Bug existed since version 4.3, commit 8550c6bd.
Trying to prepend would hang nano until some other process writes
something to the fifo.
This fixes https://savannah.gnu.org/bugs/?61236.
Bug existed since before version 2.2.4.
Benno Schulenberg