tap-only combos
okke-formsma opened this issue · comments
from makenova on discord:
Right now I use home-row-mods(hrm) but I also have combos on the home row.
My hrm are in the form of SCAG(asdf) and I also have a combo on DF.
If I want to hold alt + gui right now I have to hold one then the other or else the combo triggers if I tap them together.
With what I understand of the tap-only combos, there will be another constant defined which is > combo_term(time that a combo has to be held to trigger).
If the combo is held longer than the new constant, then the combo is not triggered but the hrm are.
oops, sorry for the assignment. I thought I had a PR open
Seconding that this would be useful. I am using tap-only combos from the early combos branch for QMK and have found it very useful for precisely the reasons stated by OP. Without it, chording HRMs that also have a combo defined becomes very cumbersome, which is unfortunate, because by design HRMs involve the most ergonomic key positions.
This is what keeps me from using zmk. Are there any workarounds?
This is what keeps me from using zmk. Are there any workarounds?
Workaround
Binding the combos to hold-taps with a hold-action equal to the corresponding combination of mods works. See example.
The downsides relative to a native solutions are:
- It's more cumbersome, especially when the combo is for behaviors other than
kp
andto
. Wrapping the hold-tap config into a macro as in the example above can alleviate the extra burden. - Dynamically adding and removing mods to a chord doesn't work. Say, you start holding index + middle, which trigger, say,
LCTRL
+LSHFT
. Now adding the ring finger won't work.
Thoughts about a native solution
Let me just add some thoughts about a possible native solution. I see two approaches for implementing a tap-only
option for combos:
- Replicate the hold-tap logic to check whether a candidate combo is held or tapped. One will need to decide what hold-tap flavor to adopt and/or whether one would expose any options?
- Instead of checking whether combos are held or tapped, check whether a candidate combo involves any hold-tap and only trigger the combo if all involved hold-taps resolve as tap.
To me, the second approach seems superior: (1) It's cleaner and does not require a re-implementation of the hold-tap logic for combos. (2) It automatically inherits any hold-tap configuration from the involved hold-taps. By contrast, the first approach would require taking a stand on a hold-tap logic that may conflict with the ones bound to the involved keys. (3) The second approach, is also easily extended to also adding a hold-only
option that triggers a combo only if all involved hold-taps resolve as hold.