3 ms·

My understanding is that control codes for [every possible modifier key combination] + ['standard' US keyboard keys] aren't all standardized. Is that correct?

My understanding is that control codes for [every possible modifier key combination] + ['standard' US keyboard keys] aren't all standardized. Is that correct? I seem to recall having a hell of a time trying to figure out which key combinations Emacs could understand and why (keyboard -> OS -> terminal emulator -> protocol -> program.) Are there any proposals? Workarounds? Proofs-of-concept?

csdvrx 4y ago
> Is that correct? It's not exactly like that - it's more like there are competing "standards" and interpretations of these standards, and sometimes supporting one means not supporting the other. Fortunately, such things are rare, and can be addressed by GUI options. Take for example SGR1 for "bold/intense" text: read the whole issue that came to Microsoft Terminal team in 2018 up to its most recent discussions on https://github.com/microsoft/terminal/issues/109 https://github.com/microsoft/terminal/issues/109 then check the "simpler" version in wikipedia https://en.wikipedia.org/wiki/ANSI_escape_code#SGR_.28Select_Graphic_Rendition.29_parameters https://en.wikipedia.org/wiki/ANSI_escape_code#SGR_.28Select... and you will realize there's no "right" answer between bold and bright (or both!), just different preferences and interpretations of the standards.
- WalterGR 4y ago
  It sounds like you’re talking about output, not input. Are there standards to represent, for example, Ctrl+Alt+* (I.e. Ctrl+Alt+Shift+8) ? Additionally with cursor keys, Insert, Delete, Backspace, F1 - F12, etc. I’ve searched several times for such standards before but never had any luck…
  - csdvrx 4y ago
    > It sounds like you’re talking about output, not input. Sorry if I misunderstood your question! However, for inputs the situation is essentially similar: the standards again depend on the terminal, and there can be multiple interpretation than can be conflicting. Take for example Control-H and Control-? : which is delete and which is backspace depend on the terminal you use! > I’ve searched several times for such standards before but never had any luck… There are sources, mostly Thomas E. Dickey (of xterm fame) but personally, I try to take an emulator and make it behave to what my fingers are doing with the minimum level of configuration. To follow up on Control-H and Control-?, here's what my .inputrc does: ### Delete to the right will be remapped to Delete "\e[3~": delete-char # keypad on . #"\eOn": delete-char # Special case for VT100 (borks backspace -> make it conditional) $if term=vt100 "\C-?": delete-char $endif ### Delete to left will be remapped to Backspace "\C-?": backward-delete-char # keypad on 5 #"\eOu": backward-delete-char # Special case for VT100 (borks backspace -> make it conditional) $if term=vt100 "\C-H" : backward-delete-char $endif (yes, the numpad delete has its own case!) Here's another one, for Control-Backspace and Control-Delete ### Line cuts will Ctrl-Backspace and Ctrl-Delete "\C-_": backward-kill-line "\e[3;5~": kill-line # Ctrl-Delete variants for tmux and urxvt "\e[M": kill-line "\e[3^": kill-line And last time I checked, Windows terminal needed proper remaps cf https://github.com/microsoft/Terminal/issues/755 https://github.com/microsoft/Terminal/issues/755 like { "keys": "ctrl+backspace", "command": { "action": "sendInput", "input": "\u0017" }, This would piggyback on "\C-h" backward-kill-word - which might be incompatible as it's got a different meaning for VT-100 as noted above. Quoting you again: > I’ve searched several times for such standards before but never had any luck… You shouldn't bother too much about that: terminals are just tools to help you do your work, and while sometimes you can use a lot of pre-existing configurations or documentation to have as much compatibility among the various standards as possible, there are other times when you need to break the standards that stand in your way. For example, I'm a Windows fan, so I believe Ctrl-C should be copy, Ctrl-V paste, and I don't really care about the traditional unixisms that would cause me try to learn to use Shift-Control-C for copy and Shift-Control-V for paste (just... no!!!) You may disagree with that, so let's take a more staightfoward example: I care even less of the more obscure unixisms like Ctrl-S/Ctrl-Q that I rarely need. Who needs to "freeze" the tty output in 2022? So in that case, I've remapped Ctrl-S to "kill word forward", something usually done with Esc-d by default. To achieve that, in my .bashrc I first clear the defaults with stty: ## Remap ctrl-c to ctrl-x to copy/paste with ctrl-c and ctrl-v, and disable ctrl-s/ctrl-q stty intr ^X stop undef start undef rprnt undef discard undef swtch undef -ixoff -ixon # The above doesn't show ^S,^Q,^R and ^O anymore in stty -a Then I can do the remappings in my .inputrc: ### Backward-kill-word is ctrl-w, while kill-word is alt|esc-d, # so instead, map ctrl-s which makes ctrl-k|u and ctrl-w|s very close "\C-s": kill-word All that to say, standards can be helpful, but there's nothing set in stone: with Control-H and Control-? already causing such headaches (but following all the standards) I don't feel so bad for abusing the standards with my use of Control-S for forward kill word, as it complements nicely the existing Control-K, Control-U and Control-W (all the 3 of which are standard BTW!)
duskwuff 4y ago
> Is that correct? Yes, this is correct. In particular, there are certain key combinations which cannot be distinguished (for example, Control+I is indistinguishable from Tab) and some keys aren't affected by modifiers (such as Shift and Control on Space). There's an extended discussion of this issue, and a proposed solution, at: http://www.leonerd.org.uk/hacks/fixterms/ http://www.leonerd.org.uk/hacks/fixterms/
WalterGR 4y ago
I think I missed a layer. keyboard -> OS -> terminal emulator -> protocol -> shell -> program And that’s for local IO… (Too late to edit my above comment.)
jart 4y ago
They pretty much are. Terminals implement CTRL keyboard shortcuts as `c ^ 0100` and ALT works by prefixing '\e'. Stuff like arrow keys encode using VT100 codes. Those are three very simple rule that everyone knows. $ wget https://justine.lol/ttyinfo.com $ chmod +x ttyinfo.com $ ./ttyinfo.com "\001" is CTRL-A a.k.a. ^A "\000" is CTRL-@ a.k.a. ^@ "\002" is CTRL-B a.k.a. ^B "\f" is CTRL-L a.k.a. ^L "\r" is CTRL-M a.k.a. ^M "\033\001" is ALT-CTRL-A "\033[A" is UP "\033\033[A" is ALT-UP Unfortunately it still leaves much to be desired. For example, have you ever wanted to have CTRL-ENTER as a keyboard shortcut in your terminal? Sadly you can't, because chr(ord('\r') ^ 0100) encodes as 'M'. Another issue is it's not possible to encode CTRL+[ as a keyboard shortcut, because it overlaps with \e a.k.a. 033 a.k.a. ASCII ESC. So if you type that shortcut, it'll cause your terminal to hang for a second. It'd be great if the standard bodies could promulgate some kind of well-defined solution to this problem. Having read the ECMA standards documents, I think they really could be doing more to focus on the people who use it for terminals!
- jmrm 4y ago
  When I found this is a valid binary both in Windows and Unix (I've tested on my Linux and BSD VMs) I found it pretty funny, but I did not expect this to being able to grab the mouse movement in Windows at all. Pretty cool!
  - jart 4y ago
    Glad you enjoyed it! If you want to read more about the technique, please see https://justine.lol/ape.html https://justine.lol/ape.html You can also support the project through Github Sponsors.

csdvrx 4y ago

> Is that correct? It's not exactly like that - it's more like there are competing "standards" and interpretations of these standards, and sometimes supporting one means not supporting the other. Fortunately, such things are rare, and can be addressed by GUI options. Take for example SGR1 for "bold/intense" text: read the whole issue that came to Microsoft Terminal team in 2018 up to its most recent discussions on https://github.com/microsoft/terminal/issues/109 https://github.com/microsoft/terminal/issues/109 then check the "simpler" version in wikipedia https://en.wikipedia.org/wiki/ANSI_escape_code#SGR_.28Select_Graphic_Rendition.29_parameters https://en.wikipedia.org/wiki/ANSI_escape_code#SGR_.28Select... and you will realize there's no "right" answer between bold and bright (or both!), just different preferences and interpretations of the standards.

WalterGR 4y ago
It sounds like you’re talking about output, not input. Are there standards to represent, for example, Ctrl+Alt+* (I.e. Ctrl+Alt+Shift+8) ? Additionally with cursor keys, Insert, Delete, Backspace, F1 - F12, etc. I’ve searched several times for such standards before but never had any luck…
- csdvrx 4y ago
  > It sounds like you’re talking about output, not input. Sorry if I misunderstood your question! However, for inputs the situation is essentially similar: the standards again depend on the terminal, and there can be multiple interpretation than can be conflicting. Take for example Control-H and Control-? : which is delete and which is backspace depend on the terminal you use! > I’ve searched several times for such standards before but never had any luck… There are sources, mostly Thomas E. Dickey (of xterm fame) but personally, I try to take an emulator and make it behave to what my fingers are doing with the minimum level of configuration. To follow up on Control-H and Control-?, here's what my .inputrc does: ### Delete to the right will be remapped to Delete "\e[3~": delete-char # keypad on . #"\eOn": delete-char # Special case for VT100 (borks backspace -> make it conditional) $if term=vt100 "\C-?": delete-char $endif ### Delete to left will be remapped to Backspace "\C-?": backward-delete-char # keypad on 5 #"\eOu": backward-delete-char # Special case for VT100 (borks backspace -> make it conditional) $if term=vt100 "\C-H" : backward-delete-char $endif (yes, the numpad delete has its own case!) Here's another one, for Control-Backspace and Control-Delete ### Line cuts will Ctrl-Backspace and Ctrl-Delete "\C-_": backward-kill-line "\e[3;5~": kill-line # Ctrl-Delete variants for tmux and urxvt "\e[M": kill-line "\e[3^": kill-line And last time I checked, Windows terminal needed proper remaps cf https://github.com/microsoft/Terminal/issues/755 https://github.com/microsoft/Terminal/issues/755 like { "keys": "ctrl+backspace", "command": { "action": "sendInput", "input": "\u0017" }, This would piggyback on "\C-h" backward-kill-word - which might be incompatible as it's got a different meaning for VT-100 as noted above. Quoting you again: > I’ve searched several times for such standards before but never had any luck… You shouldn't bother too much about that: terminals are just tools to help you do your work, and while sometimes you can use a lot of pre-existing configurations or documentation to have as much compatibility among the various standards as possible, there are other times when you need to break the standards that stand in your way. For example, I'm a Windows fan, so I believe Ctrl-C should be copy, Ctrl-V paste, and I don't really care about the traditional unixisms that would cause me try to learn to use Shift-Control-C for copy and Shift-Control-V for paste (just... no!!!) You may disagree with that, so let's take a more staightfoward example: I care even less of the more obscure unixisms like Ctrl-S/Ctrl-Q that I rarely need. Who needs to "freeze" the tty output in 2022? So in that case, I've remapped Ctrl-S to "kill word forward", something usually done with Esc-d by default. To achieve that, in my .bashrc I first clear the defaults with stty: ## Remap ctrl-c to ctrl-x to copy/paste with ctrl-c and ctrl-v, and disable ctrl-s/ctrl-q stty intr ^X stop undef start undef rprnt undef discard undef swtch undef -ixoff -ixon # The above doesn't show ^S,^Q,^R and ^O anymore in stty -a Then I can do the remappings in my .inputrc: ### Backward-kill-word is ctrl-w, while kill-word is alt|esc-d, # so instead, map ctrl-s which makes ctrl-k|u and ctrl-w|s very close "\C-s": kill-word All that to say, standards can be helpful, but there's nothing set in stone: with Control-H and Control-? already causing such headaches (but following all the standards) I don't feel so bad for abusing the standards with my use of Control-S for forward kill word, as it complements nicely the existing Control-K, Control-U and Control-W (all the 3 of which are standard BTW!)

duskwuff 4y ago

> Is that correct? Yes, this is correct. In particular, there are certain key combinations which cannot be distinguished (for example, Control+I is indistinguishable from Tab) and some keys aren't affected by modifiers (such as Shift and Control on Space). There's an extended discussion of this issue, and a proposed solution, at: http://www.leonerd.org.uk/hacks/fixterms/ http://www.leonerd.org.uk/hacks/fixterms/

WalterGR 4y ago

I think I missed a layer. keyboard -> OS -> terminal emulator -> protocol -> shell -> program And that’s for local IO… (Too late to edit my above comment.)

jart 4y ago

They pretty much are. Terminals implement CTRL keyboard shortcuts as `c ^ 0100` and ALT works by prefixing '\e'. Stuff like arrow keys encode using VT100 codes. Those are three very simple rule that everyone knows. $ wget https://justine.lol/ttyinfo.com $ chmod +x ttyinfo.com $ ./ttyinfo.com "\001" is CTRL-A a.k.a. ^A "\000" is CTRL-@ a.k.a. ^@ "\002" is CTRL-B a.k.a. ^B "\f" is CTRL-L a.k.a. ^L "\r" is CTRL-M a.k.a. ^M "\033\001" is ALT-CTRL-A "\033[A" is UP "\033\033[A" is ALT-UP Unfortunately it still leaves much to be desired. For example, have you ever wanted to have CTRL-ENTER as a keyboard shortcut in your terminal? Sadly you can't, because chr(ord('\r') ^ 0100) encodes as 'M'. Another issue is it's not possible to encode CTRL+[ as a keyboard shortcut, because it overlaps with \e a.k.a. 033 a.k.a. ASCII ESC. So if you type that shortcut, it'll cause your terminal to hang for a second. It'd be great if the standard bodies could promulgate some kind of well-defined solution to this problem. Having read the ECMA standards documents, I think they really could be doing more to focus on the people who use it for terminals!

jmrm 4y ago
When I found this is a valid binary both in Windows and Unix (I've tested on my Linux and BSD VMs) I found it pretty funny, but I did not expect this to being able to grab the mouse movement in Windows at all. Pretty cool!
- jart 4y ago
  Glad you enjoyed it! If you want to read more about the technique, please see https://justine.lol/ape.html https://justine.lol/ape.html You can also support the project through Github Sponsors.