Map keys to escape sequence #94
Comments
|
There is no paste action. Only paste_from_clipboard and paste_from_selection This should be easy to do in your OS. For example for X11: https://ubuntuforums.org/showthread.php?t=380927 if you want to rebind for only kitty. If you want to rebind globally it is even easier. |
I'm working under MacOS. Doing this globally would be quite easy, but this would interfere with my other shortcuts. Doing it application specific is theoretically possible, but would require some coding and would be a very hacky solution. https://github.com/jwilm/alacritty/blob/master/alacritty.yml#L203 |
|
As far as I know all terminals send only enter for ctrl+enter. Enter is itself a control code. ctrl+control code is meaningless. What are you actually trying to acheive? It seems like you want some terminal application to understand Ctrl+Enter. The only way to do that would be to remap it to something else, like Ctrl+a, at which point why not just use Ctrl+a? Generally speaking, classic terminal programs have very limited support for keyboard handling. For example, Ctrl+Shift does not work either. What is really needed is a new keyboard handling protocol, such as kitty supports: https://github.com/kovidgoyal/kitty/blob/master/protocol-extensions.asciidoc |
|
Oh and all available actions are listed in the kitty.conf file there is no need to read the source for it. |
|
I'm using |
|
You are going to have a tough time meeting that goal. You would have to map super+enter to some other shortcut, which is likely going to conflict with an existing shortcut in vim. Really, the proper solution is to get neovim to support the extended keyboard protocol I linked to earlier. However, I dont mind adding something like a send_text command to kitty to cause shortcuts to send arbitrary bytes. |
What protocol is that? Have you seen http://www.leonerd.org.uk/hacks/fixterms/ ? We plan to support something like that. |
|
I have seen fixterms and I did not like it. It tries to maintain compatibility with existing keyboard modes, without even being aware that there are already two different keyboard modes, so you literally cannot maintain compatibility with them in a single scheme. It does not have any method of detecting repeats and key release events. As far as I can tell it does not support multiple modifier keys and has no obvious way to be extended for new modifier keys in the future. It has no scheme for client programs to query the terminal emulator for what keyboard mode it is in. |
|
Oh and also it does not solve the problem of differentiating between esc key presses and escape codes. |
Well it sortof has to really. At least, keys like
Which two modes? Do you mean KPAM vs. KPCM? Those are somewhat annoying but in practice don't really have much effect. They just switch between two disjoint sets of possible byte sequences that the terminal could send on some keypress. Easiest is to just accept either of them, since there's never any ambiguity, then it doesn't matter which mode the terminal is in. You'll still interpret it correctly.
That I'll accept. Indeed it doesn't encode repeated keys. Those are just repeats. For key releases, I'm intending to add a mode switch to at least be aware of modifier releases, so you can do "Alt-slurring"; i.e. holding the Alt key for multiple key presses in a row. So something like
The modifier mask is a bitmask; so it can easily encode multiple at once. E.g.
Just invent more bits. 8, 16, 32, ... whatever. I'll accept they might not have wellknown names yet, but that's not hard to extend by adding a query mechanism to say "Hey, terminal, tell me the name of the 8th key modifier".
For that, you switch the terminal into |
|
On Mon, Nov 06, 2017 at 12:49:37PM +0000, Paul Evans wrote:
> It tries to maintain compatibility with existing keyboard modes,
Well it sortof has to really. At least, keys like "<Ctrl-C>" have to remain as the single-byte encoding they currently are, so that the `termios(3)` mechanisms like VINTR continue to work.
I dont see why they do. termios can turn off ISIG which means Ctrl-C
does not generate SIGINT and any application that wants handle extended key
presses will probably want to handle ctrl-c as well, without
needing to use a signal handler. Relying on in kernel handling of
key-presses was a dumb idea to start with. It made sense for hardware
terminals, it doesn't for software ones.
> without even being aware that there are already two different keyboard modes
Which two modes? Do you mean KPAM vs. KPCM? Those are somewhat annoying but in practice don't really have much effect. They just switch between two disjoint sets of possible byte sequences that the terminal could send on some keypress. Easiest is to just accept either of them, since there's never any ambiguity, then it doesn't matter which mode the terminal is in. You'll still interpret it correctly.
And yet virtually no applications actually do that. In fact, there is so
much confusion regarding those modes that it is still considered black
magic to get your home/end and arrow keys working in all shells/terminal
emulators/OSes/SSH sessions.
> It does not have any method of detecting repeats and key release events
That I'll accept. Indeed it doesn't encode repeated keys. Those are just repeats.
A repeat and multiple presses are very different. Especially in the
absence of release events. One is a key being held down, the other is a
key being tapped repeatedly. Applications might want to distinguish
between those. And even when release events are present, not having a
repeat event means every application is responsible for figuring out
what is a repeat itself, a far from trivial task.
For key releases, I'm intending to add a mode switch to at least be aware of modifier releases, so you can do "Alt-slurring"; i.e. holding the Alt key for multiple key presses in a row. So something like "Alt+12" would be different to "Alt+1 Alt+2"
Why? Isn't it just simpler to have release events?
The modifier mask is a bitmask; so it can easily encode multiple at once. E.g. Ctrl+Alt is 4 + 2, plus the offset 1, being 7.
My mistake, I missed that.
> Oh and also it does not solve the problem of differentiating between esc key presses and escape codes.
For that, you switch the terminal into S8C1T mode. In this mode, all CSI sequences coming from the terminal arrive in 8bit encoding starting with the real `0x9b` CSI byte. Now, the only time you'll ever see a true `0x1b` ESC byte from the terminal is when the user really pressed the actual "<Escape>" key. It's now entirely unambiguous based purely on the bytes received, without needing timing information.
That mode has terrible semantics. It overlaps with UTF-8, which
means you have to write a custom utf-8 decoder just to decode the byte
stream correctly. I strongly urge against using it. Applications *will*
get it wrong.
|
Well it sortof has to really. At least, keys like "" have to remain as the single-byte encoding they currently are, so that the
Which two modes? Do you mean KPAM vs. KPCM? Those are somewhat annoying but in practice don't really have much effect. They just switch between two disjoint sets of possible byte sequences that the terminal could send on some keypress. Easiest is to just accept either of them, since there's never any ambiguity, then it doesn't matter which mode the terminal is in. You'll still interpret it correctly.
That I'll accept. Indeed it doesn't encode repeated keys. Those are just repeats. For key releases, I'm intending to add a mode switch to at least be aware of modifier releases, so you can do "Alt-slurring"; i.e. holding the Alt key for multiple key presses in a row. So something like "Alt+12" would be different to "Alt+1 Alt+2"
The modifier mask is a bitmask; so it can easily encode multiple at once. E.g. Ctrl+Alt is 4 + 2, plus the offset 1, being 7.
Just invent more bits. 8, 16, 32, ... whatever. I'll accept they might not have wellknown names yet, but that's not hard to extend by adding a query mechanism to say "Hey, terminal, tell me the name of the 8th key modifier".
For that, you switch the terminal into S8C1T mode. In this mode, all CSI sequences coming from the terminal arrive in 8bit encoding starting with the real |
It doesn't overlap with well-formed UTF-8 though. Wellformed UTF-8 never starts a multibyte sequence with a C1 control byte; any of the C1 byte range (0x80 to 0x9F) UTF-8 considers to be in the continuation range. So a little bit of heuristic detection in the parser and unambiguously split a stream of UTF-8 encoded Unicode characters from C1 control sequences. I do that all the time in both Of course, it will still get confused on malformed UTF-8, but that's true in general - if you send junk bytes in who knows what will happen? |
|
I'm not saying it doesn't work, I'm saying it is easy to get wrong. I think it behooves us to come up with a protocol that is easy to implement and does not require doing things like writing a custom utf-8 parser. One of my goals is to simplify the art of writing correctly behaving terminal emulators and programs running in the terminal as well. |
|
Well alternatively if you'd prefer not to use S8C1T, just use Ofcourse, my actual answer to making things easy to implement, would be to point out to people that my libtermkey+libtickit already answers that and they should just use that already :) But maybe alternatives are also good. |
|
On Mon, Nov 06, 2017 at 01:37:59PM +0000, Paul Evans wrote:
Well alternatively if you'd prefer not to use S8C1T, just use `CSIu` encoding of the real Escape key. That does start to affect or break programs that weren't expecting it, but it avoids needing the combined C1+UTF8 parser.
But that means we are back to having a new keyboard mode anyway, since
this is not backwards compatible. If we have a new keyboard mode, why
not go the whole hog and design one from scratch, as I did?
Ofcourse, my actual answer to making things easy to implement, would be to point out to people that my libtermkey+libtickit already answers that and they should just use that already :) But maybe alternatives are also good.
I dislike the answer of making it simple by pointing to X library. Is X
library available in my programming language of choice, is it available
on my my user's computers? Is it available for operating system Y and
version Z? Why must I include an external library just to do something
as simple as encoding/decoding keyboard events? This should literally be
a few lines of code. A bitmask, a table lookup and a snprintf().
|
|
@kovidgoyal - small comment on your You document:
If you simply swapped Ctrl to be 0x4 and Alt to be 0x2, that then makes the modifiers use the same numbering sequence as xterm/et.al's CSIu encoding. |
|
@leonerd thanks, comments are welcome. Since the protocol is currently only in kitty, it can be changed based on feedback. |
|
Wow, guys, @leonerd, @kovidgoyal, thanks, this was fun to follow! :) Any important update to this nice debate, or in general, the "state of the art" of overcoming the disgusting, neglected, dusty mess of legacy keyboard handling in *n*x terminals? (I'm on the verge of losing hope and abandoning the whole notion of bare ssh sessions in favor of something over WASM, just to make decent keyboard mappings possible. Even the horrid keyboard abstraction in JavaScript seems to provide a more usable platform for this.) |
|
Nothing has happened. No one could agree on a new protocol and the effort died at the design stage https://gitlab.freedesktop.org/terminal-wg/specifications/issues/1 |
I want to map several shortcuts to other keys:
super+entertoctrl+entersuper+jtoctrl+j...
I tried the paste action, but couldn't figure out the proper format:
Is there any way to achieve this?
The text was updated successfully, but these errors were encountered: