When the guiding stripe (when softwrapping) will be shown in
a later chunk, it shouldn't be shown in the current chunk.
This fixes https://savannah.gnu.org/bugs/?57654.
Bug existed since --guidestripe was introduced, in version 4.0.
When having prepared a line for displaying on the screen, nano already
determind whether the line extends beyond the right edge or not. There
is no need to calculate again the full width of the current line later.
Just let display_string() make a note whether the piece of text that
it converted to displayable form still has more text coming after it,
and use this note when it's time to show the ">" continuation sign.
Using a static variable is ugly, but passing it along as a parameter
would be even uglier, because for all other calls of display_string()
the parameter would be just a useless burden.
(The diff is stupid. It should just remove 440 contiguous lines, and
add back 440 contiguous lines further down. Instead it tries to find
similarities between what is moved and what remains, and makes a mess.
You have to use --patience or --minimal to get the better diff.)
Any modifier keys that are needed to start the execution of a macro
(or of a string bind) should not affect the interpretation of the
keystrokes that are contained within the macro or the string.
This fixes https://savannah.gnu.org/bugs/?57660.
Bug existed since macros were introduced, in version 2.9.0.
The Shift detection on a Linux console was meant to affect only the
dedicated cursor-movement keys, not <Shift+Meta+character>.
This fixes https://savannah.gnu.org/bugs/?57598.
Indirectly-reported-by: Brand Huntsman <alpha@qzx.com>
As long as the user does not define any Sh-M-X bindings in their nanorc,
<Shift> and <CapsLock> will not have any effect on <Alt+letter> combos.
But as soon as any Sh-M-X combination is bound, <Shift+Alt+letter> will
be seen as different from the unshifted keystroke.
This kind of fulfills https://savannah.gnu.org/bugs/?54659.
Requested-by: Peter Passchier <peter@passchier.net>
This is a workaround for the VT not being able to handle zero-width
characters properly, displaying them mistakenly as visible characters.
This avoids https://savannah.gnu.org/bugs/?52954.
The problem has existed since forever, but has become noticeable
since the capability for line numbers was added in version 2.7.1.
Also, do not break overlong lines and do not convert tabs to spaces,
nor interpret a <Tab> as an indent command (when the mark is on).
In other words: accept an outside paste as literally as possible.
This fulfills https://savannah.gnu.org/bugs/?40060.
Requested-by: Egmont Koblinger <egmont@gmail.com>
And fulfills https://savannah.gnu.org/bugs/?57527.
Requested-by: Sébastien Desreux <seb@h-k.fr>
Requested-by: Hans Ecke <hecke@gxt.com>
Original-idea-by: Brand Huntsman <alpha@qzx.com>
Also, tell the terminal to switch on bracketed-paste mode, and toggle
a boolean when the start and stop sequences of such a paste are seen.
This boolean can later be used to suppress auto-indent and such.
Signed-off-by: Brand Huntsman <alpha@qzx.com>
Since the previous commit, USE_SLANG can only be defined when NANO_TINY
is also defined. This means that code that is present only in non-tiny
versions does not need to cater for Slang.
With ncurses, a window resize will cause getch() to return immediately
with some dummy value, which nano can discard. But with Slang, getch()
will return only when the next keystroke is typed, so the received code
should then not be discarded.
This fixes https://savannah.gnu.org/bugs/?57507.
The F13 to F16 function keys are no longer bound by default, and when
there is no nanorc file, there is no way to bind them, so there is no
point in recognizing their escape sequences.
Also, avoid calling a case-changing function when it's not needed.
And elide a default case that can never occur (because the function
always gets called with one of the four letters).
Nano does not do anything for the keystroke anyway (KEY_B2, the center
key on the numeric keypad, gets translated to ERR later on), so there
is no point in recognizing some of its escape sequences -- let those
sequences result in "Unknown sequence" instead.
When --rawsequences is used, consume the full escape sequences for
the F17 to F24 function keys (on xterm-compatible terminals and on
the Linux console), to prevent them entering junk into the buffer.
This fixes https://savannah.gnu.org/bugs/?57483.
Go back to how line numbers were colored in versions 2.7.1 to 4.3 --
coloring the space (when a background color is used) was unintented.
This fixes https://savannah.gnu.org/bugs/?57412.
Bug existed since version 4.4, commit 699cacf7.
Benno Schulenberg