Add "libtermkey" key bindings preset

[dragn]

See #3519

[gnachman]

libtermkey is interesting; I haven't had time to try this out yet, but it must be limited to some subset of the full libtermkey spec. Maybe this should be done in code, not as a preset, in order to make handling all key combos tractable.

This goes with gitlab issue 3519

[dragn]

Yeah, I thought so to. This is more like temporal quick fix. It fixes issues like neovim/neovim#2048 and others. But implementing all possible combinations for libtermkey would be awesome (keys bindings would not be needed in this mode...).

[gnachman]

It looks like libtermkey doesn't want a CSI code for ctrl-h based on this page: http://www.leonerd.org.uk/hacks/fixterms/

We can now represent the usual problematic keys unambiguously:
describes Ctrl-I, Ctrl-M, and Ctrl-[
Because other C0 bytes do not have usual alternative names or keypresses, these can continue to be sent using the simple single-byte encoding. This is essential to ensuring that legacy systems continue to interpret them correctly (e.g. termios still sends SIGINT on Ctrl-C).
describes Ctrl-A sending 0x01, etc.

Remapping C-h to a CSI code breaks command line editing, for example. What I don't understand is why so many people have C-h sending (which I presume is 0x7f). C-h should always send 0x08.

[jwhitley]

@leonerd, can you provide any color on the C-h vs. issues above?

[leonerd]

What sort of input are you looking for?

In an ideal world Every Single Terminal would encode as the 0x07 byte (BS), as DEL (0x7f), and as CSI 2~. It would also explain this in its own terminfo file. Then everything would work just fine.

The annoying reality of the world is that most terminfo files still claim that the Backspace key sends the ASCII BS byte, but yet programs tend to ignore that. This is the cause of the current problem - libtermkey actually believes the terminfo file to be right. A shocking concept perhaps...

I personally don't know what would be best - I can't make everyone go and fix their terminfo files. I don't know if continuing the precedent of starting to ignore what terminfo says and having parsers say "I know better" is a good idea or not.

[leonerd]

No.

Terminfo files describe the behaviour of a terminal. There isn't "one canonical correct" one any more than there is "one canonical correct" terminal. The TI file should match the behaviour of the terminal. That is first and foremost.

However, additionally it would be nice if certain properties held; such as the key encodings of the keys I mentioned above. That is a matter initially for the terminal to behave in such a manner, so that its TI file can document it.