Mac: some keys not processed on alternate keyboard layout

[neominik]

Describe the bug

I use a custom keyboard layout for normal typing (this one: https://dl.neo-layout.org/neo.keylayout) and for some reason most keys on the base layer are classified as eformat == 2 in this piece of code, so they are ignored: https://github.com/openstenoproject/plover/blob/0501aa33a0504971d1ba7452979c54798f7c3986/plover/oslayer/osxkeyboardlayout.py#L439-L446 However, these keys are found in a higher layer which has the command modifier set, so for instance typing K causes Plover to send c, Cmd+a, t, which makes it unusable for any text entry with my keyboard layout. I don't actually know what eformat is supposed to mean and I wasn't able to find any documentation on the used library, but adding the case or eformat == 2 to the first condition in the snippet above seems to add those keys just fine. If I knew what eformat was and which other side effects might arise from this change, I would open a PR, but this way I am not sure.

The repo where the code has bee copied from (https://github.com/willwade/PyUserInput/blob/master/pykeyboard/mac_keycode.py) hasn't been updated in 7 years and the used Carbon library seems to be long deprecated to the point where it is even difficult to find out what it is. Actually, I'm surprised this code is still working at all.

Alternative: Evaluate the use of a more modern input monitoring and control library such as https://github.com/moses-palmer/pynput

To Reproduce

Steps to reproduce the behavior:

1. Use the provided keyboard layout.
2. Type HE
3. See window disappear, because Cmd+H was pressed

Expected behavior

Characters on the base layer are recognized by Plover and can be sent on text entry.

Operating system

• OS: macOS BigSur
• Plover Version 4.0.0.dev10, but the linked code snippet is old.

Hardware

Both mechanical keyboard and The Uni (Gemini PR) show this behaviour.