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.
This makes the handling of plain ASCII a tiny bit slower, but it
affects only the users of --constantshow without --minibar, so...
All other uses of mbstrlen() and collect_char() are not in speed-
critical code paths.
Since the previous commit, mbwidth() is used only to determine whether
a character is either double width or zero width. There is no need to
return the actual width of the character; a simple yes or no is enough.
Transforming mbwidth() into is_doublewidth() also allows streamlining
it and is_zerowidth() a bit, so that they become slightly faster.
The number of bytes in the character were determined twice: first in
mbwidth() and then in char_length(). Do it just once, in mbtowide().
Also, avoid calling is_cntrl_char(), because it does unneeded checks
when we already know that the high bit is set.
This duplicates some code, but advance_over() is called a lot, so it
is important that it is as fast as possible.
This shouldn't slow down plain ASCII, as the extra checks (use_utf8
and *string < 0xA0) are done only for non-ASCII (apart from DEL).
The 'start_index' was in index in the given text, while 'index' is an
index in the displayable string. Having both of them using 'index' in
their name was somewhat confusing.
For a normal file (without overlong lines) the strlen() wasn't much
of a problem. But when there are very long lines, it wasted time
counting stuff that wouldn't be displayed on the current row anyway,
and reserved *far* too much memory for the displayable string.
Problem existed since commit cf0eed6c from five years ago that traded
a continuous comparison (of the used space with the reserved space)
against a one-time big reservation up front involving a strlen().
In retrospect that was not a good trade-off when softwrapping.
The extra check (charwidth == 0) is incurred only by characters that
have their high bit set, so the average file (with only ASCII) is not
affected by this -- it just loses an unneeded call of strlen().
In UTF-8 valid multibyte characters are at most four bytes long,
and now that we no longer make use of mblen() and mbtowc() from
the underlying system, we won't get five- or six-byte sequences
mistakenly reported as valid (by glibc). So it is always enough
to reserve space for just four bytes per character.
Calling wctomb() with NULL as the first parameter returns zero in a
UTF-8 locale, meaning that there is no state, so there is no point
in resetting it either.
Benno Schulenberg