3 ms·

> There is no way to see if the user pressed only Control or Shift, because from a terminal’s perspective all they do is modify a bit for the typed character.

by kps 4y ago

> There is no way to see if the user pressed only Control or Shift, because from a terminal’s perspective all they do is modify a bit for the typed character. Modern terminal emulators can do this using the xterm modifyOtherKeys protocol, which sends escape sequences for such combinations.

aumerle 4y ago
modifyOtherKeys should not be used. https://sw.kovidgoyal.net/kitty/keyboard-protocol/ https://sw.kovidgoyal.net/kitty/keyboard-protocol/ is far more comprehensive.
- kps 4y ago
  Disagree. As with the graphics discussion the other day, Kitty seems to have a NIH problem. At best, it's unnecessary extra work for other projects to support another flavour; at worst, it leads to fragmentation. Meta: I'm not among the downvoters; on the contrary I aim to upvote any on-topic reply (although I don't always get back to a thread, and anyway I suspect all my votes are shadow-ignored).
  - continuational 4y ago
    But is there any way to get modern terminal keyboard support without it?
  - db48x 4y ago
    I get why Kovid (the author of Kitty) wants to invent new protocols that improve on the existing ones (Kitty’s image protocol is quite a bit more efficient than Sixels, for example), I just don’t understand why he won’t implement both the old and the new. Supporting both Sixels and his own image protocol at the same time would be almost trivial. Of course only one keyboard protocol can be active at a time, but surely the user should be able to choose between them so that they can use software which already supports XTerm’s escape sequences.
    - aumerle 4y ago
      https://news.ycombinator.com/item?id=34422949 https://news.ycombinator.com/item?id=34422949
  - aumerle 4y ago
    You seem to be overlooking the fact the modifyOtherKeys is 1) not well designed. 2) And does not solve the problem comprehensively. 1a) try to figure out what the escape code for the play/pause key is 1b) it still suffers from the issue that esc keypresses cannot be distinguished from other escape codes 1c) The keyboard protocol can be turned on/off by user config, so there is no robust way for software running in the terminal to know if it is available or not. 1d) it does not support any modifiers beyond the basic 4 1e) It has no support for lock keys num lock/caps lock 1f) It has no support for alternate keyboard layouts 1g) it has no support for shifted keys 2) How does one represent release events in modifyOtherKeys? xterm has a long and convoluted history of coming up with poorly designed hacks that the entire ecosystem has to carry around forever afterwards. Not wanting to support these mis-faetures is an entirely reasonable position.
    - db48x 4y ago
      Escape is traditionally distinguished from an escape code by a timeout: if no more characters arrive within some small number of milliseconds, then it was the user pressing escape and not the start of an escape sequence. No new solution to that “problem” is really necessary. Likewise, programs don’t really need to know if the terminal supports an extended set of key combinations, because they can just react to them if they arrive. If they don’t arrive, then either the terminal doesn’t support that feature or the user didn’t type that key combination; either way the program needs to do nothing. As for modifiers, good look finding a keyboard that supports more than the basic four. No need for xterm to go out on a limb and support something you can’t use anyway. And who cares about num lock and caps lock? I’ve never seen any program care what state they were in. Well, GDM does warn you if capslock is on during a password prompt, but that is very niche. Terminals have never operated on scan codes, so keyboard layouts are irrelevant. The application doesn’t really care what button you pressed to get a Q, just that you typed a Q. Likewise there has never been support for key release events on terminals. I suppose it’s useful for games, but in most other situations the user will have autorepeat configured and that will handle it. Why should xterm go out on a limb and invent a scheme that tries to cover every possible future need, even needs that are not in evidence? Better to implement something simpler that just covers what is actually needed. It can always be extended later.
TacticalCoder 4y ago
I don't know about other terminal emulators but with XTerm you can modify its translation table and have any keys combo sending custom things. It's all very tricky and quite an arcane art but it's possible to get, for example, the "Hyper" modifier when Emacs is ran inside an XTerm (that is: in "-nw" / no-window mode).
arp242 4y ago
Do any terminal emulators outside of xterm implement it? While xterm is the "de-facto standard" it's also comparatively little used. Maybe I should add a section about it though; KiTTY also seems to have some new keyboard protocol thingy now.
- kps 4y ago
  I know the ones I use have it — mlterm on Linux and iTerm2 on Mac.

by kps 4y ago

aumerle 4y ago

modifyOtherKeys should not be used. https://sw.kovidgoyal.net/kitty/keyboard-protocol/ https://sw.kovidgoyal.net/kitty/keyboard-protocol/ is far more comprehensive.

kps 4y ago
Disagree. As with the graphics discussion the other day, Kitty seems to have a NIH problem. At best, it's unnecessary extra work for other projects to support another flavour; at worst, it leads to fragmentation. Meta: I'm not among the downvoters; on the contrary I aim to upvote any on-topic reply (although I don't always get back to a thread, and anyway I suspect all my votes are shadow-ignored).
- continuational 4y ago
  But is there any way to get modern terminal keyboard support without it?
- db48x 4y ago
  I get why Kovid (the author of Kitty) wants to invent new protocols that improve on the existing ones (Kitty’s image protocol is quite a bit more efficient than Sixels, for example), I just don’t understand why he won’t implement both the old and the new. Supporting both Sixels and his own image protocol at the same time would be almost trivial. Of course only one keyboard protocol can be active at a time, but surely the user should be able to choose between them so that they can use software which already supports XTerm’s escape sequences.
  - aumerle 4y ago
    https://news.ycombinator.com/item?id=34422949 https://news.ycombinator.com/item?id=34422949
- aumerle 4y ago
  You seem to be overlooking the fact the modifyOtherKeys is 1) not well designed. 2) And does not solve the problem comprehensively. 1a) try to figure out what the escape code for the play/pause key is 1b) it still suffers from the issue that esc keypresses cannot be distinguished from other escape codes 1c) The keyboard protocol can be turned on/off by user config, so there is no robust way for software running in the terminal to know if it is available or not. 1d) it does not support any modifiers beyond the basic 4 1e) It has no support for lock keys num lock/caps lock 1f) It has no support for alternate keyboard layouts 1g) it has no support for shifted keys 2) How does one represent release events in modifyOtherKeys? xterm has a long and convoluted history of coming up with poorly designed hacks that the entire ecosystem has to carry around forever afterwards. Not wanting to support these mis-faetures is an entirely reasonable position.
  - db48x 4y ago
    Escape is traditionally distinguished from an escape code by a timeout: if no more characters arrive within some small number of milliseconds, then it was the user pressing escape and not the start of an escape sequence. No new solution to that “problem” is really necessary. Likewise, programs don’t really need to know if the terminal supports an extended set of key combinations, because they can just react to them if they arrive. If they don’t arrive, then either the terminal doesn’t support that feature or the user didn’t type that key combination; either way the program needs to do nothing. As for modifiers, good look finding a keyboard that supports more than the basic four. No need for xterm to go out on a limb and support something you can’t use anyway. And who cares about num lock and caps lock? I’ve never seen any program care what state they were in. Well, GDM does warn you if capslock is on during a password prompt, but that is very niche. Terminals have never operated on scan codes, so keyboard layouts are irrelevant. The application doesn’t really care what button you pressed to get a Q, just that you typed a Q. Likewise there has never been support for key release events on terminals. I suppose it’s useful for games, but in most other situations the user will have autorepeat configured and that will handle it. Why should xterm go out on a limb and invent a scheme that tries to cover every possible future need, even needs that are not in evidence? Better to implement something simpler that just covers what is actually needed. It can always be extended later.

TacticalCoder 4y ago

I don't know about other terminal emulators but with XTerm you can modify its translation table and have any keys combo sending custom things. It's all very tricky and quite an arcane art but it's possible to get, for example, the "Hyper" modifier when Emacs is ran inside an XTerm (that is: in "-nw" / no-window mode).

arp242 4y ago

Do any terminal emulators outside of xterm implement it? While xterm is the "de-facto standard" it's also comparatively little used. Maybe I should add a section about it though; KiTTY also seems to have some new keyboard protocol thingy now.

kps 4y ago
I know the ones I use have it — mlterm on Linux and iTerm2 on Mac.