sigprof
commented
3 years ago Looks like you are using Oryx to configure the board, which implements such complex key behavior using the Tap Dance feature. Unfortunately, Tap Dance does not respect most of Tap-Hold configuration options — only the tapping term gets applied, and any other modes, such as Permissive Hold, do not affect the behavior of tap dance keys. And the implementation details of Tap Dance make implementing any mode other than an equivalent of HOLD_ON_OTHER_KEY_PRESS impossible — the tap dance code cannot delay other key events to defer the decision between a tap and a hold.
Even worse, the code generated by Oryx explicitly handles an “interrupted” tap dance (the case when you press another key while still holding the tap dance key before the tapping term had expired) as a tap, not a hold; you are probably seeing this behavior.
And yet another problem is that switching layers from tap dances requires some workarounds, otherwise in the “interrupted” case the layer switch is not applied to the next key pressed after the tap dance key. Looks like Oryx does not implement that workaround in the generated code, and with your particular configuration implementing that workaround does not even seem to be possible — the layer that would be used for the next key after the tap dance must be determined at the moment the tap dance key is pressed, and in your case it might be either 0 or 4, but it is not possible to distinguish a tap from a hold at that time.
Probably the best way to implement the behavior that you want is to use a keycode which is handled by the builtin tap-hold code (e.g., LT(), which performs an equivalent of MO() on a hold), and then replace its tap behavior as described in Intercepting Mod-Taps. If you do this, you can use all tap-hold decision modes (e.g., PERMISSIVE_HOLD or PERMISSIVE_HOLD_PER_KEY), and the other key events would be delayed if needed to perform the tap-hold decision. However, you cannot do that using the Oryx configurator or config.qmk.fm — you will need to edit the keymap as C code and compile the firmware from source.
urza
stale[bot]
github-actions[bot]
orogenic
whaaaley
This is the situation: I have Moonlander keyboard, one of the thumb key is configured as: tap: TO(0) hold: MO(4) So tapping this button goes to base layer, but holding it activates layer 4 for as long at it is hold and then goes back to whichever layer was active (0, 1, 2, 3).
Now imagine you are in layer 2 and you want to press one key from layer 4. So you hold down the thumb key plus the key you need from layer 4, then release both and you are back in layer 2. So far so good. But if you do this action too quickly (hold, press, release all within tapping term) what happens instead is that you will activate TO(0) and press key from base layer instead. Unfortunately this is very common and happens all the time to me.
It seems like permissive hold should solve this: Permissive hold If you press and release a dual-function key (e.g, Shift when held, A when tapped) and a regular key (e.g, "x") within the tapping term period, normally it would send just the tapped keys ("ax"). Enable this to ensure it sends the hold version (a shifted "x" keystroke in this case).
However it doesn't seem to work, is it because permissive hold doesn't affect MO? If so I suggest this as a feature that would be very appreciated 🥰