iTerm2 icon indicating copy to clipboard operation
iTerm2 copied to clipboard

Add "libtermkey" key bindings preset

Open dragn opened this issue 10 years ago • 7 comments

See #3519

dragn avatar May 03 '15 20:05 dragn

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

gnachman avatar May 06 '15 05:05 gnachman

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

dragn avatar May 06 '15 06:05 dragn

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 <BS> (which I presume is 0x7f). C-h should always send 0x08.

gnachman avatar May 06 '15 21:05 gnachman

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

jwhitley avatar May 12 '15 00:05 jwhitley

What sort of input are you looking for?

In an ideal world Every Single Terminal would encode <Ctrl-H> as the 0x07 byte (BS), <Backspace> as DEL (0x7f), and <Delete> 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 avatar May 13 '15 10:05 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.

leonerd avatar Dec 11 '15 11:12 leonerd