Additional configuration for HoldTap about keyberon HOT 20 CLOSED

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?

from keyberon.

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.

from keyberon.

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?

from keyberon.

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

from keyberon.

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.

from keyberon.

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

from keyberon.

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

from keyberon.

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

from keyberon.

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

from keyberon.

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?

from keyberon.

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

from keyberon.

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.

from keyberon.

tap_hold_interval seems fine too me!

from keyberon.

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.

from keyberon.

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.

from keyberon.

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.

from keyberon.

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

from keyberon.

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?

from keyberon.

Top post

from keyberon.

Working on it.

from keyberon.