Description
Since the previous kitty keyboard reporting protocol was not well received, I have implemented a new one. The new proposal is backward compatible by default producing the exact same bytes as traditional terminals. Applications that want to enable more robust key handling can use progressive enhancement to request more sophisticated behavior. Notable features:
- Distinguish between press, repeat and release events. And the four modifiers ctrl, shift, alt, and super.
- Have a "game mode" where all key events generate escape codes rather than some generating text and some escape codes
- Disambiguate all key presses. Currently, many key presses are overlapping, generate the same bytes, the most egregious example being pressing Esc.
- Allow reporting the pressed key, the shifted key and an "alternate" key in the default keyboard layout for advanced shortcut matching
- Allow sending text encoded as unicode code points within the escape code rather than as separate UTF-8 bytes. This is useful for applications that want to customise text+key event handling.
- Add a way to query for support and current progressive enhancement level. Also allow saving and restoring current enhancement level on a stack.
- Make a canonical mapping of functional key names to PUA unicode characters.
- Support any key from any language that is present in Unicode.
The new protocol has been implemented in master and will be in the next kitty release. The spec for the protocol is: https://sw.kovidgoyal.net/kitty/keyboard-protocol.html
The new escape code is based on the proposal in http://www.leonerd.org.uk/hacks/fixterms/ however, it is more general and fixes various bugs in that proposal.
If there are bugs or things I have overlooked, now is the time to point them out. You can test the implementation in kitty (which is mostly complete, barring bugs) by building kitty from master and running
kitty +kitten key_demo
inside kitty, to see how key events are reported with full progressive enhancement.
@msokalski Please check if this meets your game use case
@gnachman I believe iTerm implements some version of fixterms, so you might be interested in the bugs I discovered in that proposal
@leonerd Please look over the list of bugs in fixterms and correct me if I am wrong about anything https://sw.kovidgoyal.net/kitty/keyboard-protocol.html#bugs-in-fixterms
In particular, there is some controversy about how to encode shift+key, for instance should ctrl+shift+a be encoded as CSI 97; 6 or CSI 65; 5 IMO the former is correct. One reports the actual key pressed, not the shifted form of the key. In my spec the shifted form is available as a sub-parameter.
A general note, I will not entertain bike-shedding about the escape code format. Unless there is a serious bug or concern that causes backward incompatibility/inoperability.