Additional configuration for HoldTap

[octol]

To be able to use home row mods it's useful to able to tweak HoldTap. For example like IGNORE_MOD_TAP_INTERRUPT and PERMISSIVE_HOLD in QMK.

@TeXitoi Proposition:

The different behaviors:

• Default: our actual, corresponding to QMK default for LT, or IGNORE_MOD_TAP_INTERRUPT for MT.
• HoldOnOtherKeyPress: if a key is pressed during a HoldTap it waiting for deciding what to do, it hold now. Corresponding to the functionnality of the same name on QMK LT
• PermissiveHold: if a key is released and pressed during a HoldTap waiting, it hold now.Corresponding to the functionnality of the same name on QMK LT.

Also, we can add a tap_hold_duration corresponding to the maximal time within if you tap and hold the key, it will do the tap action, and stay holded, to allow holding the tapping behavior. (moved in #37)

It can be modeled as:

pub enum HoldTapConfig {
    Default,
    HoldOnOtherKeyPress,
    PermissiveHold,
}

pub enum Action {
    // ...
    HoldTap {
        hold: &'static Action,
        tap: &'static Action,
        timeout: u16,
        tap_hold_interval: u16,
        config: HoldTapConfig,
    },
}

That's a breaking change.

[TeXitoi]

Can you specify the different behavior, and explain who it improves the experience. The doc is quite obscure, and I always see people saying "I've modified randomly these parameters until I was satisfied".

Having a clear specification will help developping this feature, or open the discution to find something even better.

[octol]

I think this probably needs to be driven by usage experience, to find out what works. I'm will start experimenting with home row mods on my keyseebee to get some experience.

Let's start with IGNORE_MOD_TAP_INTERRUPT, which seems to be the most important one for home row mods with QMK. If I understand it correctly, by default a sequence like

    SFT_T(KC_A) Down
    KC_X Down
    SFT_T(KC_A) Up
    KC_X Up

will trigger SHIFT+a SHIFT+x even if faster than tapping term. Setting IGNORE_MOD_TAP_INTERRUPT you get the more straightforward behaviour where SHIFT+a SHIFT+x is only triggered if the modtap key is held for the entire tapping term.

How does keyberon modtap behave for such rolling combo situations?

[octol]

See also: qmk/qmk_firmware#8971
and the linked table https://docs.google.com/spreadsheets/d/1IaaOMbl6zLBb5Jswyr90Lp9hGx3xIyugVSfD_oBk4po/edit#gid=0

[TeXitoi]

I suppose you mean SHIFT+x. And it seems strange for me, if you roll, you would want ax.

In keyberon everything depend on the time the HoldTap key is holded, independently of any other keys. The other keys wait for the HoldTap to choose it's behavior, to keep key order.

[TeXitoi]

I think keyberon behave like the 2 first columns of the linked table.

[octol]

Well this is probably related to typing style. While playing around with modtap I have indeed realized that I typically roll my combos on a normal keyboard. Using modtap I've had to forcibly try to rewire my muscle memory to make it work. Looking at the linked table and the myriad ways of configuring modtap in QMK the purpose is probably to be able to fully tweak the behaviour to match the typist (rather then the other way around).

As an example I've noticed that my fingers behave differently where my pinky seems to be a lot slower in releasing a mod. The effect isn't noticeable on a standard keyboard, but very much so when using modtap.

An interesting case: https://www.reddit.com/r/ErgoMechKeyboards/comments/hdyw8c/111wpm_on_a_dactyl_manuform_with_homerow_mods_and/
which seems to do a lot of tweaking on a per key basis to make it work

[octol]

But yeah, at this point I have no concrete suggestions of how it would be useful to configure modtap. But at the same time, without being able to tweak it, it's difficult to tell what works "for me". And you are right in that a lot of people probably fiddle blindly with modtap settings in QMK until they get something that works for them

[TeXitoi]

So, as of today, keyberon is like with IGNORE_MOD_TAP_INTERRUPT. It seems a saner default to me, and is consistent with the default behavior of QMK's LT behavior. You also have per key timeout.

I think IGNORE_MOD_TAP_INTERRUPT is very popular because it allow rolling within the delay to do the tap behavior, as, when you type rapidly, you always press the next key before releasing the previous.

I think we can search the different behavior proposed by QMK, and trying to expose some comprehensive configuration flags. Then, when we have a clear proposition, we can implement a first subset, and experiment.

Note that I don't use home row modifiers, and that I think it will not suit my needs, as I use the BÉPO layout, a Dvorak like layout, making the home row keys highly used, and thus not really usable for home row modifiers.

I personally use LayerTap on the rest position of the thumbs:

• left thumb for space/navigation layer, working really well.
• right thumb for enter/numrow layer, not working really great, with unexpected enter even with a timeout at 140ms and lost enter when tapping lazily on enter. I don't see any config to fix this, maybe tap only if shorter that the delay and no other event between enter release and press?

[octol]

So, as of today, keyberon is like with IGNORE_MOD_TAP_INTERRUPT. It seems a saner default to me, and is consistent with the default behavior of QMK's LT behavior. You also have per key timeout.

Agree, and I think this default takes you pretty far too. Probably even enough for the majority

[TeXitoi]

OK, so I think I managed to extract the different behavior QMK propose, without taking into account the different timings. Basically, looking at the LT features, as the MT features have a behavior corresponding to one of LT behavior, with possibly a different timing.

So the alternatives:

• Default: our actual, corresponding to QMK default for LT, or IGNORE_MOD_TAP_INTERRUPT for MT.
• HoldOnOtherKeyPress: if a key is pressed during a HoldTap it waiting for deciding what to do, it hold now. Corresponding to the functionnality of the same name on QMK LT
• PermissiveHold: if a key is released and pressed during a HoldTap waiting, it hold now.Corresponding to the functionnality of the same name on QMK LT.

It can be modeled as:

pub enum HoldTapConfig {
    Default,
    HoldOnOtherKeyPress,
    PermissiveHold,
}

pub enum Action {
    // ...
    HoldTap {
        hold: &'static Action,
        tap: &'static Action,
        timeout: u16,
        tap_hold_interval: u16,
        config: HoldTapConfig,
    },
}

That's a breaking change.

The behavior I want for my enter key is HoldOnOtherKeyPress.

We can change the names if you have a better idea, I just retaken the QMK names.

What do you think?

[octol]

I think it looks good! And reusing the QMK names I think makes sense unless there is a good reason for it.

And a quick follow-up, should we add functionality corresponding to RETRO_TAPPING and TAPPING_FORCE_HOLD while we're making a breaking change? These probably are simpler

[TeXitoi]

RETRO_TAPPING doesn't really fit in keyberon model, as as soon as the timeout is passed, the hold action is done.

For TAPPING_FORCE_HOLD, I was thinking of something like an additional field tap_hold_interval: u16 that correspond to the maximal time between the tap release and the next press for tap action be activated directly. 0 would be equivalent do the feature disabled. Not sure of the name.

[octol]

tap_hold_interval seems fine too me!

[TeXitoi]

I've updated the spec. Ready to be implemented. If anyone start working on it, please leave a comment here.

I might give it a shot later if I have some time and it's not started by someone.

[gilescope]

Was going to mention retrotaps - they sound good. I guess there’s no harm in sending event shift down then shift up, then also immediately following a char - that would be the equivalent of a retrotap.

[TeXitoi]

Well, they don't seems that good in practice https://precondition.github.io/home-row-mods#home-row-mods-order

I think better to put a long timeout than using retro tap.

[TeXitoi]

He has removed its blog post that seems to be a wip. Here is what I wanted to link: https://github.com/precondition/precondition.github.io/blob/b5d08e13da2ca75b10c3e58226dfe030d4faa4ea/_posts/2020-11-01-home-row-mods.md#retro-tapping

[octol]

I've updated the spec. Ready to be implemented. If anyone start working on it, please leave a comment here.

Sorry which spec is this referring to? Didn't spot any in the repo?

[TeXitoi]

Top post

[TeXitoi]

Working on it.