This is common knowledge already, but the Esc key to change modes was chosen because it made sense when used in ADM-3A[1], which was the terminal used to develop the initial vi version.<p>Although many people today use Caps Lock for this, the Esc in these terminals was originally in Tab's position.<p>[1] <a href="https://en.wikipedia.org/wiki/ADM-3A" rel="nofollow noreferrer">https://en.wikipedia.org/wiki/ADM-3A</a>
That's one of the reasons why custom keyboards are in demand: you can do all the remapping on firmware level (QMK, etc) and they will work in any application and any OS.
When it's an input event in Linux, and you want direct control over what it does, it ultimately ends in writing a daemon with libevdev to get the device event. At least, that is what happened to me last time.
I’ve recently spent some time working with terminal emulators in raw mode on macOS. While I chose to handle key events using escape codes, and found it seriously difficult (even gave up) to process the shift modifier key. However, I came across xquartz [1], which seems to do similar things as mentioned in the article. Would detecting shift key state have been trivial using such a library?<p>[1] <a href="https://github.com/XQuartz/XQuartz">https://github.com/XQuartz/XQuartz</a>
I wrote a more elaborate remapping a while ago and loved having more modifiers that allowed me to have arrow keys and ctrl+shift on my homerow. But the way the keyboard is handled is a bit of a mess in linux, especially now that Wayland is used for some applications. Like my terminal would not use the modified keyboard config.<p>I also regularly switch between keyboard layouts and when I switch from eg. Chrome to the terminal the keyboard layout changes.
I've just finished writing an essay where I talk about my recent experiments with X and managing keyboard events. If you've had similar experiences or have any thoughts to share that could help clarify things even more, I'd really like to hear your thoughts.