The combination of prefer_hold=True and tap_interrupted=True is an extremely useful setting that allows to both minimize typos and doesn't feel as sluggish to use as prefer_hold=False.
This behavior is default in ZMK which is en exemplary firmware in terms of "ergonomic" features.
Unfortunately, when applied in context of LayerTap, whether through KC.MT or KC.HT, pressing and releasing a key within tap_time produces weird results.
Sidenote:
Since KC.MT is now just an alias for KC.HT, I think it should be deprecated completely.
To Reproduce
Steps to reproduce the behavior:
Setup and configuration of the affected parts of the firmware (avoid copy-pasting the entire configuration if possible)
Describe the bug
The combination of
prefer_hold=True
andtap_interrupted=True
is an extremely useful setting that allows to both minimize typos and doesn't feel as sluggish to use asprefer_hold=False
. This behavior is default in ZMK which is en exemplary firmware in terms of "ergonomic" features. Unfortunately, when applied in context of LayerTap, whether throughKC.MT
orKC.HT
, pressing and releasing a key withintap_time
produces weird results.Sidenote: Since
KC.MT
is now just an alias forKC.HT
, I think it should be deprecated completely.To Reproduce Steps to reproduce the behavior:
1.
TEST2
is pressedKC.F
is pressedKC.F
is released withintap_time
TEST2
is released Result: stuckf
2.
TEST2
is pressedTEST3
is pressedTEST3
is released withintap_time
TEST2
is released Result:f
, which is the tap output ofTEST3
located on the same layer asTEST2
TEST2
,TEST3
andKC.F
are all located on the same layer.TEST1
is omitted for brevity as it produces the same result asTEST2
Expected behavior Expected results are:
enter
located on layer 3backslash
located on layer 3Debug output If applicable, add debug output from the serial console to help explain your problem.
Additional context Add any other context about the problem here.