To determine the logical key that was pressed, we previously just
trusted that the translated text would have the right value. But if
modifiers are pressed, the text may not translate.
For example on macOS, Ctrl+C does not produce any text. As a result, we
would fall back to the physical key. On layouts like Dvorak, the
physical key for "C" is "I". This means "Ctrl+C" sequences weren't
working.
Instead, if there is no text or the text doesn't map to a key, we
translate again using no modifiers to try to get the raw text of the
input and then base the key on that.
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.
Fontconfig in particular appears unsafe to initialize multiple times.
Font discovery is a singleton object in an application and only ever
accessed from the main thread so we can work around this by only
initializing and caching the font discovery mechanism exactly once on
the app singleton.
I went and downloaded a couple different programs that use
UCKeyTranslate and dumped their values since I cannot find the header
file and then wrote a unit test to make sure we stay accurate here.
