-
-
Notifications
You must be signed in to change notification settings - Fork 3.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
On-release option for positional-hold-taps #1423
On-release option for positional-hold-taps #1423
Conversation
d552e9c
to
dcc2f37
Compare
Tank you for trying to solve the problem with chording mods and using Same goes for rolling 20 and 19, there I get an / {
behaviors {
// 0 1 2 3 4 5 6 7 8 9 10 11
// 12 13 14 15 16 17 18 19 20 21 22 23
// 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39
// 40 41 42 43 44 45 46 47 48 49
rhm: right_home_row_mod {
compatible = "zmk,behavior-hold-tap";
label = "RIGH_POSITIONAL_HOLD_TAP";
#binding-cells = <2>;
tapping-term-ms = <200>;
bindings = <&kp>, <&kp>;
hold-trigger-key-positions = <0 1 2 3 4 5 12 13 14 15 16 17 24 25 26 27 28 29 30 31 40 41 42 43 44>;
hold-trigger-on-release;
};
lhm: left_home_row_mod {
compatible = "zmk,behavior-hold-tap";
label = "LEFT_POSITIONAL_HOLD_TAP";
#binding-cells = <2>;
tapping-term-ms = <200>;
bindings = <&kp>, <&kp>;
hold-trigger-key-positions = <6 7 8 9 10 11 18 19 20 21 22 23 32 33 34 35 36 37 38 39 45 46 47 48 49>;
hold-trigger-on-release;
};
};
keymap {
compatible = "zmk,keymap";
default_layer {
bindings = <
&kp TAB &kp Q &kp W &kp F &kp P &kp B &kp J &kp L &kp U &kp Y &kp SEMI &kp BSPC
&mt LCTRL ESC &lhm LCTRL A &lhm LALT R &lhm LGUI S &lhm LSHFT T &kp G &kp M &rhm LSHFT N &rhm LGUI E &rhm LALT I &rhm LCTRL O &mt RCTRL SQT
&kp LSHFT &kp Z &kp X &kp C &kp D &kp V &kp LBKT &kp GRAVE &caps_word &kp RBKT &kp K &kp H &kp COMMA &kp DOT &kp FSLH &kp RSHFT
&kp LG(LSHFT) &kp LCMD &mt LALT RET &kp SPACE &mo NAV &mo SYM &kp SPACE &kp RALT &kp RGUI &kp HYP
>;
};
};
}; |
Thanks for reporting. This is to be expected due to the default flavor being "hold-preferred", which triggers when another key has been pressed (bypassing the key-position check which is delayed until key release). I suggest using the "balanced" or "tap-preferred" flavor along with this feature. |
Thank you for your response, and thanks for your efforts, with |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Working with this branch for one week now, and it is working perfectly fine
I have been using this branch for a few weeks now as well, no problems with it, I would love to see it merged. It fixes the major problem I had with positional hold-taps which is not being able to combine multiple holds on the same side. |
Thanks! I have been using it as well without issues for quite a while now. @petejohanson from my side it's ready to be reviewed |
I'm using this commit in my zmk fork and this works great for the balanced flavor. The status quo hold-trigger-key-position behavior is unusable for me with the balanced flavor at least and I was very happy to discover this branch existed. The approach taken by this commit is quite elegant and straightforward, it would be nice to see it merged someday. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
One minor nitpick on the updated conditional. This also should have a new test added to assert the updated additional behavior option and it's functionality.
if (((!undecided_hold_tap->config->hold_trigger_on_release && ev->state) // key pressed | ||
|| (undecided_hold_tap->config->hold_trigger_on_release && !ev->state)) // key released |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This can be simplified to undecided_hold_tap->config->hold_trigger_on_release != ev->state
>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
good catch, done
Done. I have tests for all 3 main flavors but only committed the one for balanced so far since the flag is meaningless for the other ones. But if you prefer I can upload them as well. |
@urob can you please rebase against latest |
69abe2e
to
9d4b775
Compare
Done. I noted those netlify deploy failures but didn't know where they came from and what to do about (they weren't there when I first pushed this branch). But looks like they are resolved after the rebase. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks!
PR introducing `hold-trigger-on-release` has been merged into ZMK -- zmkfirmware/zmk#1423
PR introducing `hold-trigger-on-release` has been merged into ZMK -- zmkfirmware/zmk#1423
This fixes #1363 by adding a
hold-trigger-on-release
option to positional hold-taps.When
hold-trigger-on-release
is set totrue
, it delays the evaluation ofhold-trigger-key-position
until the next key's release. This is in contrast to the current behavior, which evaluateshold-trigger-key-positions
upon the next key press. The current behavior is not always ideal, for example for homerow mods, because it prevents combining multiple modifiers on the same hand.The new
hold-trigger-on-release
configuration allows combining multiple modifiers when held, while still forcing a tap-decision when the next key is tapped.Note: Due to the delay of the position-check until key release, the property has no effect when using the
hold-preferred
flavor (which triggers mods when another key is pressed). The property is most useful when combined with thebalanced
ortap-preferred
flavor.Example configuration: