[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Nano-devel] when the terminfo info does not match the terminal
From: |
Benno Schulenberg |
Subject: |
[Nano-devel] when the terminfo info does not match the terminal |
Date: |
Thu, 20 Dec 2018 20:04:54 +0100 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 |
Op 19-12-18 om 20:18 schreef Benno Schulenberg:
> Aaah. So when you type Ctrl+H (on those terminals where <Bsp> produces
> 7f), nano sees 107 (KEY_BACKSPACE)? But... on those terminals this is
> because of a mismatch between terminfo database and terminal, [...]
So... in general, we cannot be certain that the info that is selected
from the terminfo database, on either a local or remote machine, matches
what the used terminal actually produces. :|
But even when things are mismatched completely, we still want nano
to work correctly -- or at least be able to make it work correctly
by giving it an option.
Of only two things can we be certain: that the <Backspace> key and
<Delete> key produce different codes, and that the terminfo entry
will define different codes for kbs and kdch1. Of one thing we can
be reasonably certain: that when we get a ^H (0x08), the intended
action is 'backspace' -- looking in the terminfo.src of ncurses-6.1,
there are only a few obscure terminals where ^H means something else
(but never 'delete').
There are quite a few terminals where kdch1=^?, but when so, then
always kbs=^H. So... if we are on a terminal that actually produces
^? for <Delete> and ^H (or something else) for <Backspace>, and the
terminfo entry mistakenly says kbs=^? (and something else for kdch1),
then...
1) ^H will pass through ncurses untranslated, and will do a backspace
anyway, so we don't need to do anything about that;
2) ^? will be translated by ncurses to KEY_BACKSPACE, which will do a
backspace -- even using --rebinddelete (-d) will not change that; only
when using also --rebindkeypad (-K) will ncurses skip the translation
and will nano see the ^? (DEL_CODE) and then --rebinddelete will cause
it to do a 'delete' instead of a 'backspace'.
So... when the terminfo information is correct, there never is a problem.
But when the info is wrong, and the <Delete> key does a backspace, never
--rebinddelete by itself will correct the problem. Maybe we should make
--rebinddelete imply --rebindkeypad?
(By the way, --rebindkeypad should have been called --rawsequences or
--rawcodes or something, because it effectively leaves the keypad keys
"unbound", unmangled, untranslated.)
Benno
signature.asc
Description: OpenPGP digital signature
- Re: [Nano-devel] [RFC] is it time to break free from the Pico defaults, (continued)
- Re: [Nano-devel] [RFC] is it time to break free from the Pico defaults, David Ramsey, 2018/12/18
- Re: [Nano-devel] [RFC] is it time to break free from the Pico defaults, David Ramsey, 2018/12/19
- Re: [Nano-devel] [RFC] is it time to break free from the Pico defaults, David Ramsey, 2018/12/19
- Re: [Nano-devel] [RFC] is it time to break free from the Pico defaults, David Ramsey, 2018/12/19
- Re: [Nano-devel] [RFC] is it time to break free from the Pico defaults, David Ramsey, 2018/12/19
- Re: [Nano-devel] [RFC] is it time to break free from the Pico defaults, David Ramsey, 2018/12/19
- Re: [Nano-devel] [RFC] is it time to break free from the Pico defaults, David Ramsey, 2018/12/20
- Re: [Nano-devel] [RFC] is it time to break free from the Pico defaults, David Ramsey, 2018/12/20
- Re: [Nano-devel] [RFC] is it time to break free from the Pico defaults, David Niklas, 2018/12/24
- Re: [Nano-devel] [RFC] is it time to break free from the Pico defaults, David Niklas, 2018/12/28