[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Nano-devel] [RFC] is it time to break free from the Pico defaults
From: |
David Ramsey |
Subject: |
Re: [Nano-devel] [RFC] is it time to break free from the Pico defaults |
Date: |
Thu, 20 Dec 2018 15:20:53 -0600 |
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.
- 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/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 <=
- 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