tap-only combos

[okke-formsma]

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.

[okke-formsma]

oops, sorry for the assignment. I thought I had a PR open

[urob]

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.

[anderso]

This is what keeps me from using zmk. Are there any workarounds?

[urob]

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 and to. 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:

1. 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?
2. 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.