Re: [Nano-devel] [RFC] is it time to break free from the Pico defaults

[David Ramsey]

Benno Schulenberg:
> 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.  :|

Right.  It's one of those cases where what *should be* doesn't match
what *is*.

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

Right again.

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

Right.  (Well... if they produce the same code and/or have the same
terminfo entry, that's something we can't work around, and something the
terminal author really needs to fix on their end.)

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

Right.  ^H being Backspace is an ASCII standard (which is what UTF-8 is
backwards compatible with, as well), and used in both dumb terminals and
ANSI terminals, so I think it's something we can reasonably assume.

> There are quite a few terminals where kdch1=^?, but when so, then
> always kbs=^H.

Right, because ^? being Delete is also an ASCII standard.

> 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;

Right.  (Unless ^H is used for another terminfo entry, of course.)

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

Right.

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

It seems that way, yes.

> Maybe we should make --rebinddelete imply --rebindkeypad?

Hmmm.  That seems like a good idea, but it would need to be tested
first, just to make sure.

> (By the way, --rebindkeypad should have been called --rawsequences or
> --rawcodes or something, because it effectively leaves the keypad keys
> "unbound", unmangled, untranslated.)

Probably.  It's difficult to come up with names for some of these options.