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.
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 mblen() and mbtowc() functions will happily return 4 or 5 or 6
for byte sequences that start with 0xF4 0x90 or higher. But those
sequences encode for U+110000 or higher, which are not valid Unicode
code points. The libc of FreeBSD and OpenBSD and Alpine correctly
return -1 for such sequences. Make nano behave correctly also when
linked against glibc, so that invalid sequences are always presented
as a series of invalid bytes and never as a single invalid code.
This fixes https://savannah.gnu.org/bugs/?60262.
Bug existed since before version 2.0.0.
The call of this function in make_mbchar() does not add anything,
because wctomb() already returns -1 for codes U+D800 to U+DFFF,
and parse_verbatim_kbinput() already rejects anything that starts
with U+11.... or higher, so make_mbchar() is never called for codes
beyond U+10FFFF.
And the call in display_string() just needs to check for wc <= 0x10FFFF
because mbtowc() already returns -1 for codes U+D800 to U+DFFF.
Having a block cursor present when highlighting a match...
does not look nice. So... hide the cursor until the next
keystroke, unless --showcursor or 'set showcursor' is used.
This makes the cursor move smoothly left and right -- instead of
"stuttering" when passing over a zero-width character.
Pressing <Delete> on a normal (spacing) character also deletes
any zero-width characters after it. But pressing <Backspace>
while the cursor is placed after a zero-width character, just
deletes that zero-width character. The latter behavior allows
deleting and retyping just the combining diacritic of a character
instead of the whole character.
This addresses https://savannah.gnu.org/bugs/?50773.
Requested-by: Mike Frysinger <vapier@gentoo.org>
When nano reports "Unbound key" or "Unknown sequence", this message
should stay onscreen only for the relevant keystroke, not for any
succeeding keystroke.
This addresses https://savannah.gnu.org/bugs/?59119.
Bug existed since before version 2.0.6.
The tiny version is about being small, not about convenience features
that hardly anyone uses anyway.
Also exclude the description of the "+line[,column]" feature -- it is
unneeded verbosity.
This addresses https://savannah.gnu.org/bugs/?59101.
The constant cursor display must be suppressed whenever a message
was printed to the status bar. That is: whenever 'lastmessage' is
something other than 'VACUUM'.
By default, this function is bound to ^L, to make that keystroke do
something actually useful. To not lose the Refresh function that this
keystroke had, the centering function additionally does a full redraw
and refresh of the screen.
This gives quicker feedback, and spares the user unnecessary beeps
and typing. Also, now a beep after a <Tab> means just one thing:
there are NO completions.
This fulfills https://savannah.gnu.org/bugs/?58627.
The parameter was referenced in just one place. So, simply check for
the three relevant menus (and unrestricted mode) and be done with it.
This also has the pleasant effect that the menu name is now the first
parameter of do_prompt(), thus clearly indicating what prompt it is,
instead of having an opaque TRUE or FALSE value at the beginning.
Benno Schulenberg