mirror of
https://github.com/ghostty-org/ghostty.git
synced 2025-07-16 08:46:08 +03:00
a1e70afbb1
See: https://github.com/mitchellh/ghostty/issues/242#issuecomment-1678268533 Quoted: @hovsater OKAY! I've consulted _the source_, i.e. `xterm`. None of the other reference material was illuminating and there is so much conflicting implementation out there and so very few terminals actually support `modifyOtherKeys`. I believe I've figured it out. I believe that `C-S-h` is only supported via `modifyOtherKeys` state 2. iTerm emits it for state 1 but I think this is a mistake and I can't get any other terminal to do it, including `xterm`. Here is my test script on Linux: ``` printf "\x1b[>4;1m" # change to "2" for state 2 showkey -a ``` With state 1, I couldn't get any terminal to output anything for `C-S-h`. **But with state 2, xterm outputs: ** `CSI 27;6;72~`. One thing to note is 72 is `H` (uppercase), so in even this case, iTerm appears to be sending the wrong code or `dte -K` is outputting the wrong case (less likely I think). When I launch `dte` (the full editor), it only requests `modifyOtherKeys` state 1. So, with only `modifyOtherKeys` support, it shouldn't get access to `C-S-h`. Note that I couldn't get any terminal on macOS to show the same sequences as xterm under any circumstance. I also cracked open the `xterm` source and I only eyeballed it but I believe this is not sending the sequences under state 1: https://sourcegraph.com/github.com/ThomasDickey/xterm-snapshots@c2b36af8d216926b8931c6f9cebefd69228e437c/-/blob/input.c?L579 **I could be very wrong, I'm not confident.** Every implementation (and there are only few) seems different and the behaviors are not consistent at all. Hence, I'm falling back to `xterm`, but even then I could be reading the source wrong. But when I ran `xterm` manually I could only get `C-S-h` to show up in state 2.