[Feature Request] Improved home row modifiers

[argenkiwi]

Feature Request Type

• Core functionality
• Add-on hardware support (eg. audio, RGB, OLED screen, etc.)
• Alteration (enhancement/optimization) of existing feature(s)
• New behavior

Description

I would like QMK to provide better support for home row modifiers. My understanding is that the current implementation does not take into account typing streaks to reduce lag when typing. Bilateral combinations to prevent accidentally triggering chords with the fingers of the same hand can also reduce errors. It would be good to be able to specify a timeout so the standard repeat action of a key is executed if no other key is pressed. I am aware of some attempts to improve the status quo:

• Achordion
• sm_td
• HRM endgame (?)
• UPDATE: Chordal Hold (I missed this before creating the issue, looks promising!)

I am personally coming from software based solutions like keyd and kanata with which I obtained much better outcomes with significantly less effort. I have recently tried to migrate to a VIAL based solution and I am struggling to get anything acceptable for production use. I suggested an improvement to home row modifiers for VIAL and shared it as a Reddit post. I was surprised it hadn't been requested already and I am even more surprised it has not been requested here, considering how many seem to think it is necessary and also seem to know for sure this is the right place to ask.

[filterpaper]

Duplicate of #24262

[amarz45]

I wouldn't say this is a duplicate, because my issue asks for only one of the things listed here.

[filterpaper]

My understanding is that the current implementation does not take into account typing streaks to reduce lag when typing.

The solution in #24262 achieves this by eliminating lag if the interval from the previous key is shorter than a user specified timeout. Hold-tap keys will be registered as tap on key-down. Unless "typing streak" is a nomenclature for a different behaviour. This is the context of duplication.

Bilateral combinations to prevent accidentally triggering chords with the fingers of the same hand can also reduce errors.

Pull request #24560 is the solution for this particular behaviour.

It would be good to be able to specify a timeout so the standard repeat action of a key is executed if no other key is pressed.

This behaviour is unfortunately slightly unclear.

[argenkiwi]

Thanks for the comments.

#24262 does look as a potential solution to the typing streak problem. I am aware of a different approach that specifies the length of the streak and evaluates the time elapsed since the start of the streak. This is a feature request and therefore agnostic to which solution is implemented in the end.

#24560 does look like a great candidate for solving bilateral combinations and I am not aware of any significantly different approach to it other than the ones already mentioned in the PR.

The timeout I am referring to is a concept I borrowed from projects like keyd and Kanata. In essence, when a timeout is applied to a home row modifier, if the user holds the key for longer than the timeout, the key code associated to the tap gesture for that key is emitted and, if the user continues to press it, it repeats as it would in a standard non programmable keyboard. If there is a way to achieve this already, I apologize but I'm not aware of it.

I posted this issue as a feature request including many of the aspects that make usable home row modifiers feasible (that I know or heard about) because all are important. I refrained from suggesting implementation details, the list of existing attempts to solve this is just for reference and to demonstrate it is an issue that attracts lots of interest.

Of course, I leave it to the maintainers to assess the value of this feature request as well and when to consider it resolved or closed.

[filterpaper]

The timeout I am referring to is a concept I borrowed from projects like keyd and Kanata. In essence, when a timeout is applied to a home row modifier, if the user holds the key for longer than the timeout, the key code associated to the tap gesture for that key is emitted and, if the user continues to press it, it repeats as it would in a standard non programmable keyboard.

When a user holds the mod-tap key down longer than TAPPING_TERM, the modifier is registered (current default behaviour). And if the user continues holding it down longer than your specified timeout, the modifier is unregistered and the tap cold is then sent instead?

[argenkiwi]

I am actually not sure how the tools I mentioned implement this. It could either be that the modifier is registered after the tapping term and then the tap code is registered if the timeout is reached or it may be that the modifier is never registered if no other key is pressed afterwards. For the win/super key it would make a difference I suppose, because tapping it does have actions assigned to it on Windows and Linux.

The most noticeable use case for this I personally observed is MacOS's special character tooltips, which show up after pressing and holding a character. As a Spanish speaker I would not want to sacrifice that for HRMs if it can be helped.

[filterpaper]

I am actually not sure how the tools I mentioned implement this. It could either be that the modifier is registered after the tapping term and then the tap code is registered if the timeout is reached or it may be that the modifier is never registered if no other key is pressed afterwards. For the win/super key it would make a difference I suppose, because tapping it does have actions assigned to it on Windows and Linux.

The most noticeable use case for this I personally observed is MacOS's special character tooltips, which show up after pressing and holding a character. As a Spanish speaker I would not want to sacrifice that for HRMs if it can be helped.

The question was not about how other tools implement it, but rather how you expected it to behave in addition to the current press or hold decision that is governed by TAPPING_TERM. The two solution linked above are the most common enhancement to home row mod-taps. This third "timeout" you mention seems uncommon, thus these questions on how it should work, timing-wise.

[argenkiwi]

Maybe I am making it sound more complicated than it is. What I would expect is there being another setting, global or key-specific, to set a timeout for the holding action (HOLDING_TERM?) which should be higher that the tapping term (I set this to 500ms generally). If the home row modifier key is held for the duration of the holding term or more, the key code defined for tapping is emitted (fall through). It should be optional as many would not want to have to worry about how long they've kept the HRM down.

I am a new user of a VIAL device and my understanding of QMK and firmware-based keyboard customization is limited. I bring up keyd and kanata because it's what I'm familiar with them and both support this. I didn't think it was uncommon, but I recognize this particular aspect may be relevant to only a minority of the users.

[filterpaper]

Have you implemented and tested both solution, especially #24560? That pull request will benefit from more real world use case feedback. Your tests and approval of that PR increases confidence for that change to be merged and it fulfils one of your feature request.