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.
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 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.
That is: pause a little to jolt the user, and then leave the message
on the status bar.
This fixes https://savannah.gnu.org/bugs/?61147.
Bug existed since version 4.8, commit 416386ed.
This fixes https://savannah.gnu.org/bugs/?61146
Bug existed since version 2.3.2, since --locking was introduced,
and continued to exist since version 4.8 despite commit 497f126b
claiming to have fixed it.
When safe_tempfile() returns a valid filename, it should also
return a valid open stream.
This fixes https://savannah.gnu.org/bugs/?61064.
Bug existed since version 1.3.8, commit 5e068c60.
Having a local variable that gets assigned to just once looks rather
poor. To me it makes more sense to have two separate exit points: one
for failure somewhere in the middle, and one for success at the end.
This way it is completely clear which value gets returned when.
When there is just one row, the user wants to see text on this row,
not a bar with some meta info.
This fixes https://savannah.gnu.org/bugs/?60508.
Bug existed since version 5.5, since the minibar was introduced
with commit d31cc373.
Whenever softwrap was toggled on or line numbers were toggled on/off or
the window was resized, the extra rows per line needed to be recomputed
for ALL the lines. For large files with many long lines this was too
costly.
(This change causes the indicator to have an incorrect size when there
are many softwrapped chunks onscreen, but that will be addressed later.)
This fixes https://savannah.gnu.org/bugs/?60429.
Problem existed since version 5.0, since the indicator was introduced.
When inserting a file into the current buffer, the 'fmt' element will
already be set. When we avoid overwriting the current value of 'fmt'
(when it's other than UNSPECIFIED), we don't need to save and restore
the value when inserting a file.
When saving the buffer under a different name, it should by default
have the same format as the original file.
This fixes https://savannah.gnu.org/bugs/?60278.
Bug existed since version 2.6.0, commit 0293eac1.
This improves the fix for https://savannah.gnu.org/bugs/?60269,
by not dropping error messages that happen before a buffer is opened.
This basically reverts commit b63c90bf from a year ago, except that
it now always deletes the created buffer when the user does not want
to override the lock file, also when it is the only buffer.
Set the 'format' of a file only when it has been fully read in,
so that this field can be used to indicate that any later error
message cannot be meant for this buffer.
This fixes https://savannah.gnu.org/bugs/?60269.
Bug existed since commit 6bf52dcc from yesterday.
When opening multiple files and some of them had an error, only the
first message was shown and the others were lost -- indicated only
by three dots. Improve upon this by storing the first error message
for each buffer and showing this message when the buffer is first
switched to.
Requested-by: Mike Frysinger <vapier@gentoo.org>
When the version number is a trio, the version string will occupy
ten bytes and the terminating NUL byte would not be written (which
was not a problem as byte 12 of the lock data is zero anyway).
But it's better to not have the compiler complain, so allow writing
the terminating NUL byte outside of the ten bytes reserved for the
version string.
When a large piece of text or code is pasted or inserted, it could
contain matches for start= and end= regexes, and backtracking from
the current screen could mistake an end for a start and could thus
miscolor things. Avoid this by recalculating the multiline cache
for pastes and insertions that cover more than a screenful.
This fixes https://savannah.gnu.org/bugs/?59982.
Bug existed since version 2.6.0, but existed also before 2.4.3.
Show leading dots for the truncated part, or (if there is no room
at all) show just an underscore instead of the file name.
This fixes https://savannah.gnu.org/bugs/?59802.
Bug existed since version 2.9.3, commit 97cbbb0c.
