[Top][All Lists]

[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),

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.)


Attachment: signature.asc
Description: OpenPGP digital signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]