Shift + layer 4 cursor keys not working
Closed this issue · 6 comments
From this comment:
CapsLock/Right Cmd + qwerty-asdf are the cursor keys. But adding shift to select text does not work, but did before.
I should check whether other keys in layer 4 might be useful with the shift modifier.
Similarly, Cmd+⌫ (backspace, though possibly labeled delete) is used to delete files in Finder, but Cmd+Mod4+V (Neo) (i.e., Cmd+Layer4Backspace) triggers Cmd+V instead.
I guess the underlying mechanism is the same as for shift.
I suppose in theory any key from the upper layers could be combined with Cmd, or at least any key that is present on a standard keyboard. E.g., Finder also has examples for numbers and /
:
Here’s a list of keys we might consider for modification:
- Layer 3:
- Symbols that are present on conventional keyboard layouts:
_[]^!<>=&\/{}*?()-:@#$|~`+%"';
- Probably not: elipsis
…
, long sſ
, and "slashing dead key" from the middle three rows and the entire top (number) row, all of which can’t be typed on a standard layout
- Symbols that are present on conventional keyboard layouts:
- Layer 4 numblock:
- numbers
0-9
- numbers
- Layer 4 navblock:
- PgUp ⇞, PgDown ⇟, Tab ⇥, Delete ⌦, Escape ⌧, Backspace ⌫, directional Arrows ←→↑↓, Enter ↲
- maybe: Home ⇱, End ⇲ (with pitfalls related to #1)
- probably not: Insert ⎀, Undo ↶
This is just meant as a starting point. Not all modifier–key combinations are reasonable or feasible (e.g., Layer 3 cannot be combined with Shift, since that’s Layer 5).
I made a commit that should mostly fix this. Can you test whether it works for you? I did not test all potential key combinations, but if it seems to work for common ones, I can fix others on a case by case basis when noticed.
I did not address key combinations involving layer 3. This would need to be addressed via the keyboard layout file. But apart from that I don't think it is possible in a reasonable way because the layer 3 modifier key is option/alt. As such in combination with other modifier keys (cmd, shift) it should act as option/alt and map to layer 1.
But apart from that I don't think it is possible in a reasonable way because the layer 3 modifier key is option/alt. As such in combination with other modifier keys (cmd, shift) it should act as option/alt and map to layer 1.
That’s a good point. I tried to test both Layer 4 and Layer 3 keys with modifiers, but I’m not sure what a reference to test again would be. Different applications interpret things differently (presumably based on which API they access).
For example, I tried setting up a binding for Mod4+N = ¿
(for the sake of argument), which was interpreted as:
App | Interpretation |
---|---|
system shortcuts* | ⌥⇧Ü |
Keyboard Maestro | ⇧S |
IntelliJ IDEA | ⌥D |
* Preferences → Keyboard → Shortcuts (this is presumably as “definitive” as it gets)
For other keys / combinations, results varied just as much. Given this variety, I suggest taking a pragmatic approach and seeing what problems — if any — come up in practice.
As it happens, all the Finder bindings in the screenshot above now work perfectly.
For example, I tried setting up a binding for Mod4+N = ¿
Shortcuts with such keys will be problematic in general because that key combination remaps to two key combinations with different modifiers “pressed” in succession (the first one presses a dead key and the second one determines the character to be printed given the dead key state). So depending on the application it might register either the first or the second key combination. The first will be the same for all keys of this sort, the second one corresponds to a key combination involving a different layer (e.g., ⇧S). So either one is not the desired shortcut.
I'm closing this as this should be fixed for the key combinations where it is possible to add additional modifiers and I believe it won't be (easily) fixable for other key combinations.