Achieve this by translating KEY_SUSPEND back to ^Z.
(Strictly speaking, this is incorrect, as the terminfo entry
might specify some other keystroke for 'kspd', but... meh.)
This fixes https://savannah.gnu.org/bugs/?61573.
Bug existed since before version 2.2.0, since keys became rebindable.
With --zero, any message that was there will get overwitten by the
text window anyway as result of the current operation. And with
--minibar, any message will get overwritten with the minibar.
This fixes https://savannah.gnu.org/bugs/?61539.
Bug existed since commit 03637030 from two weeks ago.
The unsetting should happen after the three possible early returns,
to avoid leaving the flag unset.
Also, don't bother to exclude the setting and unsetting from the
tiny version, to get rid of some cluttering conditionals.
Only requested information (^C, M-D) and alerts stay onscreen until the
next keystroke, but less important messages are overwritten after 1.5
seconds (or 0.8 seconds with --quick). This makes the behavior more
consistent with dropping a message when there is a spotlighted match.
This fragment suppressed the cursor when it was on the bottom row of
the terminal and a message was displayed on the status bar. But since
commit a2a00577 from eight days ago, the cursor will be scrolled off
of the bottom row when there is a message.
Also when adjusting the viewport, after the cursor has gone offscreen
(by toggling the help lines, for example), should the SHIM be applied.
This fixes https://savannah.gnu.org/bugs/?61503.
Bug existed since commit 03637030 from last week.
It's an editor -- the largest element should be the text to be edited,
not some part of the interface.
(It would be better if the edit window was always the largest element,
larger than or equal to all interface elements combined. But that is
something for another time.)
Messages like "Search Wrapped" and "This is the only occurrence"
do not need to be shown until the next keystroke. Dropping them
quickly gives a better fullscreen experience.
This needlessly wipes the status bar when --constantshow is active,
but it already needlessly wiped it when --minibar is active, so...
It is not a performance issue. It was just a small optimization.
(Plus, with --zero, nano does a full edit_refresh() when in fact
only the bottom row needs to be redrawn, but there is no easy way
to do that when --softwrap is active, so...)
(Using --constantshow with --zero doesn't make sense, but the user
might want to have the --constantshow when they toggle --zero off.)
With --zero or 'set zero', nano will hide the title bar or the minibar
(whichever is active) and will use all rows of the terminal for showing
the text of the buffer. Only when there is an important message will
it be shown on the bottom row -- until the next keystroke.
This feature can be toggled with M-Z.
The feedback at startup ("Read nnn lines") is suppressed with --zero,
because it disrupts the fullscreen experience (and is hardly useful).
The "Reading..." message then needs to be suppressed too, otherwise
it creates an annoying little flash.
There are still some issues that need to be addressed:
* In the browser, when the highlighted item is on the bottom row, it
will get obscured by the prompt bar or the "Search Wrapped" message.
* In the edit window, when the search occurrence is on the bottom row,
it can get obscured by the "This is the only occurrence" message.
* When tabbing at a prompt shows possible completions, they are shown
a row too low.
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.
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.
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>
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.)
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).
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.
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.
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.
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.
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.
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 '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().
Benno Schulenberg