Discussion/Feature request: Better handling of chorded mods with positional hold-tap feature

[urob]

When using the positional hold-tap feature with home-row mods, in order to "chord" mods, one has to include same-hand HRMs in the hold-trigger-key-positions. E.g., if one wants to chord LSHFT and LCTRL located on the left index and middle fingers, one has to include both keys in the hold-trigger-key-positions for these two keys.

Unfortunately, this often defeats the purpose on keyboard layouts where the most common letters are placed on the home row as well. While it doesn't hurt to enable positional hold-taps for non-home-row keys, most misfires are likely to occur on the home-row.

It would be great to add an option that allows for chording of same-hand mods. I am not sure of what would be the best set of rules to achieve this. Below are some initial thoughts based on a discussion on discord.

In their QMK implementation, @manna-harbour managed to allow for mod-chording of keys that aren't included in hold-trigger-key-positions. If I understand correctly, they do so by changing the mod-hold to a tap only when the next key is a tap.

One question about this approach is how it interacts with ZMK's global-quick-tab setting. If global-quick-tap takes precedence, then the 2nd mod-tap would most likely be turned into a tap (given that chording is usually fast), and hence the exemption wouldn't apply. On the other hand, if the contemplated "next-key-hold-trigger-exemption-rule" takes precedence, this would effectively disable global-quick-tap on the home row.

Finding a good rule set is definitively a challenge here and may require some more complex rules. But it would be nice to have a discussion about potential solutions.

[jmding8]

It sounds like you are describing a need for tap-trigger-key-positions?

[urob]

It sounds like you are describing a need for tap-trigger-key-positions?

Is that a PR? I couldn't find anything but just based on the name this sounds indeed like what I propose.

[urob]

Just realized that there might be a very simple fix for this by simply applying the positional-hold-tap logic upon key-release (currently it is decided upon key-press).

I implemented a small proof-of-concept hack that does this. Based on my limited testing it works great. Here's the testing branch if someone wants to try it out. https://github.com/urob/zmk/tree/positional-hold-tap-on-release

[urob]

Added a PR (#1423) that adds the fix as an optional config option