Miryoku And homerow mods

Oh, and just as another explanation for the different modes of my hrm macros:

If you switch to hrm-off, you don’t get any hrms.
If you switch to hrm-on, you get Level 3 - hrms with same-hand avoidance.
If you switch to hrm-auto, you get Level 4 - hrms with same-hand avoidance and fast typing streak block-out.

1 Like

This parameter allows to set key positions that will trigger hold-tap resolution only for the positions in the provided list. If hold-tap is interrupted by a key that is not in the list, it immediately is interpreted as a tap.

This is the relevant excerpt from my ZMK config:

#define LEFT_HAND_KEYS   \
     0  1  2  3  4  5    \
    12 13 14 15 16 17    \
    24 25 26 27 28 29

#define RIGHT_HAND_KEYS  \
                          6  7  8  9 10 11 \
                         18 19 20 21 22 23 \
                         30 31 32 33 34 35

#define LEFT_THUMB_KEYS  \
             36 37 38 

#define RIGHT_THUMB_KEYS \
                         39 40 41

           lsht: left_shift_tap {
                compatible = "zmk,behavior-hold-tap";
                flavor = "balanced";
>               hold-trigger-key-positions = <RIGHT_HAND_KEYS RIGHT_THUMB_KEYS>;
                hold-trigger-on-release; // for combining HRMs
                tapping-term-ms = <U_TAPPING_TERM>;
                quick-tap-ms = <U_QUICK_TAP>;
                #binding-cells = <2>;
                bindings = <&kp>, <&kp>;
            };
            rsht: right_shift_tap {
                compatible = "zmk,behavior-hold-tap";
                flavor = "balanced";
>               hold-trigger-key-positions = <LEFT_HAND_KEYS LEFT_THUMB_KEYS>;
                hold-trigger-on-release; // for combining HRMs
                tapping-term-ms = <U_TAPPING_TERM>;
                quick-tap-ms = <U_QUICK_TAP>;
                #binding-cells = <2>;
                bindings = <&kp>, <&kp>;
            };

So, when I hold a key with a bound right_shift_tap behavior (e.g. K in Qwerty) and immediately tap any key on the left half, it is immediately interpreted as Shift+Left-Side-Key. But, when I hold the right_shift_tap behavior key, and either tap or hold (interrupt) any key on the same right side, it is immediately interpreted as a tap, no delay. So, I can roll the keys on the same side without being afraid of triggering any combination, and no delay, as if the were no Hold-Tap keys.

hold-trigger-on-release helps combining mods on the same side, that is, delays the resolution of Hold-Tap keys held on the same side and with set hold-trigger-key-positions, till the end of the initial (of the one held first) Hold-Tap resolution.

I did not follow this thread, but from the look of it, it may be very similar to what your macro does, except that in ZMK it’s a core Hold-Tap feature, and in QMK, it is provided as a third-party lib that is integrated with hooks.

PS: In my ZMK config, I have separated Shift behaviors from other mods behaviors. Other mod behaviors are even more restricted:

            rmt: right_mod_tap {
                compatible = "zmk,behavior-hold-tap";
                flavor = "balanced";
                hold-trigger-key-positions = <LEFT_HAND_KEYS LEFT_THUMB_KEYS>;
                hold-trigger-on-release; // for combining HRMs
                tapping-term-ms = <U_TAPPING_TERM>;
                quick-tap-ms = <U_QUICK_TAP>;
>                require-prior-idle-ms = <U_STREAK_DECAY>;
                #binding-cells = <2>;
                bindings = <&kp>, <&kp>;
            };

That is, U_STREAK_DECAY ms is required to pass after the last key press before any Hold-Tap resolution is even considered, so it’s a tap before they elapse.

2 Likes

Great explanation how all this is connected with UHK at the current state of its firmware. Also well done with the macro! Totally agree on the proposed improvements to the firmware.

I think urob meant that all the mentioned improvement up to Level 4 are part of “timeless” HRM. The way he explains things makes me think that all these improvements help one avoid relying on “mind” timers, the ones that one has to run in their head not to mess typing. In other words, you just type naturally and do not think about distracting delays and the such. Also you sort of get rid of many delays, introduced by the resolution process.

2 Likes

@proostas Awesome, thanks for the explanation. Yes, this is pretty much what I did with the same-hand avoidance (it’s just defined the other way round, listing the “other hand” keys).

And require-prior-idle-ms is of course the equivalent to the typing streak block-out that I implemented with the timer macro.

I completely agree. With the right features (macros), I just keep typing and it “just works”. No need to force myself to introduce typing delays.

1 Like

Ah, now I get your use of require-prior-idle-ms. You are blocking out mods during the typing streak except Shift. That one you keep enabled to allow easier typing of CamelCaseCapsWords etc. That makes a lot of sense.

1 Like

You mentioned somewhere else that you were inspired by the Kanata HRM options. Your Kanata setup includes basically the same concept you made available through the UHK macros?

Yes, it uses the same features (same-hand avoidance, auto-deactivation during typing streaks). The only difference is that the current Kanata config only triggers the streak auto-deactivation on the primary hrm keys, not all alpha keys. On the UHK, I’ve put macros on all alpha keys.

I intend to update that in Kanata, too, but haven’t found the time for it yet. (It’s less pressing for me now that HRMs work so well on the UHK…)

1 Like

That difference between Kanata config and UHK config was annoying me, so I just fixed it. The Kanata config now also auto-deactivates hr-mods on all alpha keys (while fast typing). Updated config is in my github.

2 Likes