An invalid UTF-8 starter byte should not be represented in the same way
as a valid Unicode character.
This fixes https://savannah.gnu.org/bugs/?59832.
Bug existed since two weeks ago, since the mini-bar code was merged.
The first byte of a multi-byte UTF-8 sequence must be in the range
0xC2...0xFF. Any other byte cannot be a starter byte and can thus
immediately be treated as a single byte.
When space is too tight to show all three elements, show the report on
the number of lines in preference to the current location and character
code. The latter two will be shown again upon the next keystroke, so
there is little harm in hiding them for a moment.
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.
Remarks are about unsurprising things but it's good to give feedback
on them; "mistakes" are unexpected things, and get colored like an
error; and information is something that the user requested and thus
needs to stay on the status bar until the next keystroke.
For some reason, calling halfdelay() undoes the ISIG mask.
So, mask keyboard interrupts again immediately after the call.
Reported-by: Peter Passchier <peter@passchier.net>
Instead of redisplaying the minibar only upon the next keystroke
(when some feedback message is shown on the status bar), time the
waiting for the keystroke out after four fifths of a second, then
redisplay the minibar and continue the wait.
The bottom window (the prompt bar and the shortcuts) does not shift
its position when line numbers are active, so mouse clicks in this
window should be not be compensated for the line-numbers margin.
This fixes https://savannah.gnu.org/bugs/?59749.
Indirectly-reported-by: ObeliX <ObeliX-@gmx.de>
Bug existed since version 2.7.0, since line numbers were introduced.
The state flags are relevant only when editing.
This fixes https://savannah.gnu.org/bugs/?59744.
Indirectly-reported-by: ObeliX <ObeliX-@gmx.de>
Bug existed since version 5.3, since --stateflags was introduced.
This allows using <Esc> <Esc> <letter> in a macro as an alternative
for <Ctrl+letter>, but it does require that one does not type <Esc>
by accident when recording a macro as it might modify the subsequent
keystroke when the macro is replayed.
This fixes https://savannah.gnu.org/bugs/?58904.
Bug existed since version 3.0, commit ecc9211a.
The workaround was for https://savannah.gnu.org/bugs/?51335
(a cursor-misplacement bug), but both an recent Xfce Terminal
and a recent Konsole appear unaffected by the issue. So, drop
the workaround for modern systems.
Checking for the actual version of libvte is too complicated, so
assume that libvte is 0.58 or newer (where the problem is fixed)
when ncurses is 6.2 or newer.
This avoids unnecessarily truncating the last help item on the
very bottom row when there is still plenty of room.
This fixes https://savannah.gnu.org/bugs/?59550.
Bug has been visible since at least version 2.5.1.
(Yes, the test is for 6.0, but the bug was actually fixed in 5.9,
as far as I remember -- I just wasn't sure and didn't want to bother
building different versions of ncurses myself.)
The terminal window in the graphical Debian installer (the default)
produces the same escape sequences as xterm for F1 to F4. Though
TERM is set to xterm, the xterm terminfo data is not available, so
ncurses is unable to translate the sequences for us. :| Therefore,
recognize the relevant raw escape sequences.
Also, eat all bytes of the non-recognized modified function and arrow
keys, so that they do not enter junk into the buffer.
The tiny version is probably only ever used in the Debian installer,
on the bterm terminal, which produces escape sequences like those of
a Linux console. So, exclude all other raw sequences.
(After support for Slang has been removed, we can maybe even exclude
ALL raw sequences from the tiny version, and the corresponding option
(-K/--rawsequences) too.)
At least since version 229 of xterm (from August 2007), the escape
sequences for F1 to F4 have been "Esc O P" to "Esc O S". There is
no bracket in those sequences, and there probably never was -- most
likely the extra "[" in nano's code was a slip of the fingers.
Benno Schulenberg