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.
Curses cannot function if not informed via TERM which type of terminal
is being used. As many terminals are mostly compatible with a VT220,
falling back to "vt220" when TERM is unset has a good chance of giving
the user a usable nano, instead of simply failing.
(Falling back to "vt100" is not good as it contains padding delays.)
This partially addresses https://bugs.debian.org/991982.
In the terminal font that I use nowadays (that deals well with
combining characters), the normal diamond exceeded the boundaries
of a single cell and thus partly covered the first character of
the relevant line.
When a segment of text is extracted, copy any anchors that it has
into the cutbuffer, so that they get saved in the undo item, so that
an undo will put these anchors back on the lines where they were,
instead of leaving an inherited anchor at the top of the segment.
And when text is pasted, clear any anchors in it, so that they will
not travel nor multiply.
This fixes https://savannah.gnu.org/bugs/?61162.
Bug existed since version 5.0, since anchors were introduced.
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.
The documentation (https://www.haiku-os.org/docs/api/libroot.html)
says that BSD extensions are enabled by default, but somehow this
does not seem to be the case on my system. With _DEFAULT_SOURCE
defined, though, src/files.c now compiles fine.
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.
Any error message will already have been written to the terminal by
statusline(). Also, "Buffer not written to" looked too much like
"Buffer written to"; one had to look closely to see the difference.
Make sure that when multiple nanos with nameless buffers die,
each of them tries saving those buffers to different files.
This addresses https://savannah.gnu.org/bugs/?60902.
Reported-by: Julian Rosen <julianrosen@gmail.com>
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.
And make the wording for the --historylog option similar.
This fixes https://savannah.gnu.org/bugs/?60868.
Bug existed since version 2.3.0, commit 8e2a9307, since the
saving and restoring of the cursor position was introduced.
When something that is called from die() calls die() again,
there is nothing we can do any more but give up.
This would have prevented the spiralling as
seen in https://savannah.gnu.org/bugs/?60853.
This mitigates a problem seen sometimes among the Red Hat crash reports:
somehow wgetch() keeps returning ERR, as if it were in nodelay mode.
(I've seen this happen once after nano came out of suspension.)
Using a much larger error-count value gives the user a few seconds
to type something and hopefully get out of the error condition.
Calling die() could trigger another call of emergency_save(), which
could fail and cause another call to statusline(), which would call
die() again... Spiralling until stack space runs out.
This fixes https://savannah.gnu.org/bugs/?60853.
Bug existed since version 5.1, commit 7942dab0.
Original report was in https://bugzilla.redhat.com/1976410.
Reported-by: Souptik Dutta Roy <duttaroy.souptik@gmail.com>
In Dejavu Sans Mono the old pointing triangles had a decent size,
but in Noto Mono and in Ubuntu Mono (fonts that handle combining
diacritics better) those triangles were massive, visually taking
up more than a single cell, overlapping the closing parenthesis
when they are displayed in the second column. Not nice.
The new pointing small triangles look good in the Noto and Ubuntu
fonts, but are real tiny in Dejavu. :| Oh well, one can't have
everything.
(Other triangles are not an option, because they don't degrade to
actual arrows when on a Linux console.)
When the spotlighting needs to be cancelled, there is no need to do a
full refresh of the edit window -- redrawing just the relevant line is
enough. (And when there is just one row, it is enough too.)
We want to reduce the size of the answer by one byte,
not keep the full answer (plus terminating NUL).
This fixes https://savannah.gnu.org/bugs/?60764.
Bug existed since version 2.9.8, commit f304b9ae,
since piping text to an external command was introduced.
When it is not specified, it defaults to the value for 'titlecolor'.
When not using --minibar, I want the title bar to be blue (as that is
how I've always had it), but with --minibar, I want this mini bar to
be grey, as otherwise it reminds me too much of the prompt bar.
Also, colorize 'set minicolor' as valid in a nanorc file.
Even though I know that spotlighted text is not selected, I still
regularly think for a fleeting instant that the spotlighted text
can be cut with a ^K. Mitigate this by dropping the spotlighting
after 1.5 seconds (or 0.8 seconds when using --quick).
This can be useful when wanting to search for the other occurrences
of some (long) string in the buffer: select, M-6, ^W, ^U, <Enter>.
Signed-off-by: Hussam al-Homsi <sawuare@gmail.com>
Nano already opens the relevant file (when needed) and puts the cursor
at the relevant spot -- including this information in the message shown
on the bottom bar is just clutter and makes the message harder to read.
The die() has been there for more than a year and no one reported a
problem. And anyway, indenting does not create more than one group
-- this check was just to be certain.
Because "lightnormal" sounds strange, and can have unexpected effects.
This fixes https://savannah.gnu.org/bugs/?60668.
Bug existed since version 2.9.5, since the name "normal" was introduced.
When using +/ or +?, any minor feedback should be cleared,
to not distract from the highligted search result.
This fixes https://savannah.gnu.org/bugs/?60669.
Bug existed since version 5.5, commit b86f7868,
since the manner of grading status-bar messages changed.
After a "+" only c, r, C, and R are valid characters,
and only when immediately followed by / or ?.
This fixes https://savannah.gnu.org/bugs/?60667.
Bug existed since version 4.4, commit 2326bf6,
since searching at startup with +/ or +? was introduced.
The "^_" has always been poorly legible (the underscore melting into
the bottom of the terminal) and difficult to type (Shift+Ctrl+minus).
The "^/" is both more readable and easier to type.
In terminal emulators, "^/" is shown, but on a Linux console "^-",
as ^/ does a backspace in the default console key mapping.
Also, allow using "^-" when rebinding ^_ in a nanorc file.
This addresses https://savannah.gnu.org/bugs/?57393.
Simply adding the number of bytes in the quoting part is not entirely
correct, but... currently the indenting and commenting routines also
assume that the whitespace and commenting characters that are added or
removed are single-byte characters... It will require another patch
to make this all fully correct, but for the default configuration
(and probably most other cases) the current fix will work fine.
This fixes https://savannah.gnu.org/bugs/?60605.
Bug existed since version 4.4, commit 8fce33af from two years ago,
since this automatic copying of the quoting part was introduced.
This fixes https://savannah.gnu.org/bugs/?60596.
Bug existed since version 4.4, commit 8fce33af from two years ago,
since this automatic copying of the quoting part was introduced.
When on a one-row terminal a message gets automatically "dropped"
after a few moments, the subsequent waiting for a keystroke should
not think that there is still a message on the status bar.
This fixes https://savannah.gnu.org/bugs/?60591.
Bug existed since commit 8d974cd2 from two days ago.
When there is just one row and there is a message, it is not a good idea
to draw the contents of the buffer as it would overwrite the message.
This fixes https://savannah.gnu.org/bugs/?60582.
Bug existed since version 2.7.0, since nano allows very flat terminals,
and was made worse by commit 2cf28f9d from yesterday.
Redraw the content of the edit window (for the undone final completion)
before pushing out the "No further matches" message, so that the latter
will not get overwritten by the buffer content -- in case the terminal
has just one row.
This fixes https://savannah.gnu.org/bugs/?60581.
Bug existed since commit 2cf28f9d from yesterday.
Only important error messages (ALERT) and information that the user
requested (^C, M-D) should stay put until the next keystroke. Other
messages should be overwritten by the text of the buffer after just
a few moments, to make a one-row terminal slightly more friendly.
This addresses https://savannah.gnu.org/bugs/?60570.
When showing a message on the status bar, the cursor should be off.
This fixes https://savannah.gnu.org/bugs/?60510.
Bug existed since version 2.7.0, since nano allows very flat terminals.
When there is just one row, the text to be edited needs to be shown
there, not some meta information about the cursor position.
This fixes https://savannah.gnu.org/bugs/?60563.
Bug existed since version 2.7.0, since nano allows very flat terminals.
Since version 5.6, commit 76742cc1, nano highlights the search match,
which means that the screen gets refreshed anyhow, so this specific
refresh for a one-row terminal is no longer needed.
This prevents read() from returning unexpectedly and causing a crash.
This fixes https://savannah.gnu.org/bugs/?60537.
Reported-by: Filips Romāns <frfilips@gmail.com>
Bug existed since version 2.4.2, since the handling of SIGWINCH changed.
That is: call edit_refresh() right away, to prevent the edit_refresh()
in the main loop from overwriting the status-bar message.
This fixes https://savannah.gnu.org/bugs/?60516.
Bug existed since version 2.7.2, commit f920e0d3.
That is: call edit_refresh() right away, to prevent the edit_refresh()
in the main loop from overwriting the status-bar message.
This fixes https://savannah.gnu.org/bugs/?60518.
Bug existed since version 5.6, commit 76742cc1.
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.
This reduces startup time by seven percent (when using the standard set
of syntaxes) when opening just one file that doesn't match any syntax,
and more than ten percent when opening multiple files. It takes some
extra memory, but... not wasting CPU cycles is more important.
This addresses https://savannah.gnu.org/bugs/?56433.
When undoing several actions, it is possible for the line at the top
of the screen to be removed, leaving 'edittop' pointing to a structure
that has been freed. Soon after, 'edittop' is referenced to determine
whether the cursor is offscreen... Prevent this invalid reference by
stepping 'edittop' one line back in that special case. This changes
the normal centering behavior of Undo when the cursor goes offscreen,
but... so be it.
When a single node is deleted, it is always possible to step one line
back, because a buffer contains always at least one line (even though
maybe empty), so if the current line could be deleted, there must be
one before it (when at the top of the screen).
This fixes https://savannah.gnu.org/bugs/?60436.
Bug existed since version 2.3.3, commit 60815461,
since undoing does not always center the cursor.
Since two commits ago, the position of the indicator shows the position
of the viewport relative to the full buffer in terms of actual lines,
not of visual chunks (to avoid excessive computation). But the size of
the indicator stayed constant, as if it always covered as many lines as
the edit window has rows. But the latter will not be the case when
softwrapping occurs. Therefore, when softwrapping, compute how many
actual lines are visible in the viewport, and adjust the size of the
indicator accordingly.
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.
Benno Schulenberg