"Fixing" home row mod accidental fires via SM_TD implementation

[brandonbeaumia]

I recently stumbled upon a new QMK library meant to fix homerow mod implementations, and it kind of blew me away with its simplicity. I've seen a few people report that it is extremely effective with minimal configuration. The breakdown of how it works is on its wiki page at https://github.com/stasmarkin/sm_td/wiki; that page does a great job in just a couple paragraphs and one ASCII art of showing the concept: it's based on release timing instead of press timing.

My post here is two-fold:

1. The concept is very simple, but I'm not sure how it might be implemented in Kanata. I'm desperate to get HRM working reliably so even if it's a lot of work or a kind of hacky, I would love to mimic this release-timing based implementation.
2. If it doesn't seem feasible to implement in Kanata, what sort of feature(s) might be added to Kanata that would make it possible?

[jtroo]

You can have a look at this issue and the associated PR (and other links) to see how it might be implemented. I don't foresee any major hurdles to implementing it.

• Expand the support for custom tap-hold function #128
• https://github.com/jtroo/kanata/pull/343/files

[brandonbeaumia]

Oh, I'm sorry! I think I miscommunicated in my initial post. I used the term "implement" in the context of a config, not within the code itself. Unfortunately, my programming experience is functionally zero. I'll switch to using "configure" here to clarify. On the chance you really did mean that the feature(s) linked in #128 were enough to configure this feature, could you elaborate to point me in a more specific direction? Otherwise, let me know if it is more appropriate to open a feature request instead and I will gladly write one up.

[jtroo]

I can't think of a way to implement sm_td via existing Kanata functionality.

[gerhard-h]

For QMK getting mod_tap and tap_dance unified is certainly a good thing, and the readability seem to be decent. I still wonder if the same results can be achieved with kanata?

SMTD_TIMEOUT_TAP - that's the timeout within tap-hold
SMTD_TIMEOUT_FOLLOWING_TAP - this is about when to prefer tap-hold over tad-hold-release,... I think that is QMK internal to fight back against PERMISSIVE_HOLD
SMTD_TIMEOUT_SEQUENCE - this is about fast typing detection, wich can be done with

  tp (multi
    (one-shot 95 (layer-while-held fast-typing))
    (on-idle  95 tap-virtualkey to-base-layer )
  )

in kanata

SMTD_TIMEOUT_RELEASE - I don't really get how to properly use this and compare to kanata.
I assume with a per key config it can be used to make hold for Shift more likely to happen than hold for Crtl.

but in both SMTD and kanata you may need to fix some key roles/multi taps with switch/fork/chord

for reference:
SMTD_TIMEOUT_TAP
This is the time in ms between macro key press and release to consider it as a tap action. So if you press and release a key within this time, it will be considered as a tap action. If you hold a key longer than this time, it will be considered as a hold action.

SMTD_TIMEOUT_FOLLOWING_TAP
This is the time in ms between following key press (second after macro key pressed) and release to consider macro is still might be a tap action. In other words, if you hold both macro and following keys longer than this time, macro key will be considered as a hold action.

SMTD_TIMEOUT_SEQUENCE
This is the time in ms between two macro taps to consider them as a sequence of taps.

SMTD_TIMEOUT_RELEASE
This is the time in ms to consider two keys released within that period as a hold action for the first key and a tap action for second. If two keys has bigger time between their releases, they will be considered as a tap action for both keys.

[brandonbeaumia]

SMTD_TIMEOUT_RELEASE - I don't really get how to properly use this and compare to kanata.

This is the release comparison timing, and I think the primary innovation (as far as I know) of SM_TD. In the chart below (from the wiki), this variable would represent the 2ms timing from 49ms to 51ms. So A and B both detect properly as Hold,Tap because they are released very close to each other. Order of release doesn't matter, just the proximity. And C detects properly as Tap,Tap because even though all three scenarios have the same amount of overlap between keys, the spaced release timing means it was much more likely a roll than an intentional Hold activation.

0ms  - - | - ┌—————┐ - - - - - | - ┌—————┐ - - - - - | - ┌—————┐ - - - - - |
         |   │macro│           |   │macro│           |   │macro│           |
         |   │ key │           |   │ key │           |   │ key │           |
         |   │     │           |   │     │           |   │     │           |
10ms - - | - │     │ ┌—————┐ - | - │     │ ┌—————┐ - | - │     │ ┌—————┐ - |
         |   │     │ │foll.│   |   │     │ │foll.│   |   │     │ │foll.│   |
         |   │     │ │ key │   |   │     │ │ key │   |   │     │ │ key │   |
         |   │     │ │     │   |   │     │ │     │   |   │     │ │     │   |
         |   │     │ │     │   |   │     │ │     │   |   │     │ │     │   |
         |   │     │ │     │   |   │     │ │     │   |   │     │ │     │   |
         |   │     │ │     │   |   │     │ │     │   |   │     │ │     │   |
49ms - - | - │     │ └—————┘ - |   │     │ │     │   |   │     │ │     │   |
50ms - - | - └—————┘ - - - - - | - └—————┘ │     │ - | - └—————┘ │     │ - |
51ms - - | - - - - - - - - - - | - - - - - └—————┘ - |           │     │   |
         |                     |                     |           │     │   |
         |                     |                     |           │     │   |
         |                     |                     |           │     │   |
         |                     |                     |           │     │   |
200ms  - | - - - - - - - - - - | - - - - - - - - - - | - - - - - └—————┘ - |  ```

[gerhard-h]

the ms values in this example diagramm are odd, and I would interpret this input completely different:
I agree case A and B should be handeled the same way, but
hit and relase two keys within 51ms - I forcefully treat these as two taps
In case C it looks like we wait for 200ms till the second letter is printed, that would feel extremly laggy. instead after 40-60ms I would interpret this as a hold operation. would be cool to test this on a real keyboard.