A control code cannot be a Meta keystroke, and a plain printable
character as key code necessarily means it is a Meta keystroke.
So, comparing just the key code is enough.
Note that DEL_CODE (0x7F) will never occur as input key code, because
it gets translated to KEY_DC in the input routine (or to KEY_BACKSPACE
when --rebinddelete is in effect).
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>
Since ^@ is rebindable too and also a synonym of ^Space, it makes
more sense to allow the user to specify ^` instead, as it is an
unshifted keystroke on US keyboards.
Also, color ^` as valid in a nanorc file, and color ^` and ^@ in
the help viewer.
The meta flag needs to be suppressed only for the self-defined
<Meta+arrow> key codes.
This fixes https://savannah.gnu.org/bugs/?57643.
Bug existed since commit 5130c35b from a few hours ago.
Some key strings map to the same key code, so to unbind also a string's
synonyms, go through the list comparing against the key code. It has
the additional advantage that it is faster: a plain value comparison
instead of a string comparison.
There is no need to compare also the meta flag, because plain printable
ASCII characters (from 0x20 to 0x7E) cannot be shortcuts, so when such
a character matches, it necessarily means it is a meta keystroke.
This fixes https://savannah.gnu.org/bugs/?57397.
When assign_keyinfo() gets passed zero as key code, it will call
keycode_from_string() to determine the key code from the string.
So, remember the key code when keycode_from_string() gets called
the first time to avoid the second call.
When the mark is set at the current cursor position, and then something
is pasted (either with ^U or from outside of nano), then this entire
pasted text should be marked -- just like when it had been typed. So,
the mark's position should not be adjusted not only when it is located
before the cursor but also when it is at the same place as the cursor.
This fixes https://savannah.gnu.org/bugs/?57631.
Bug existed since version 2.0.7.
Just like nano beeps when an unbound key is pressed at other prompts,
or in the help viewer, or in the file browser.
Signed-off-by: Brand Huntsman <alpha@qzx.com>
The suppression of auto-indentation, automatic hard-wrapping, and
tab-to-spaces conversion is now inherent in the way the reading-in
of a bracketed paste is handled by the previous commit: as a single
block of text.
This makes an external paste (with mouse or <Shift+Insert>) behave
the same as an internal paste (^U), and also inherently suppresses
auto-indentation, automatic hard-wrapping, and tab conversion.
This fulfills https://savannah.gnu.org/bugs/?54950.
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.
(The ideal behavior would be that nano would warn the user beforehand,
before the file that is being edited by someone else gets overwritten,
but that would require many more changes. So... just give a helpful
warning -- that's already better than it was.)
(When the new or changed name is that of an existing file AND this
file is being edited by some other editor (or nano itself), then the
behavior is rather strange: nano asks whether to continue, but the
file has already been overwritten and there is nothing the user can
do to cancel or revert things. A later commit should improve this.)
This fixes https://savannah.gnu.org/bugs/?47975,
and fixes https://savannah.gnu.org/bugs/?53883.
