feat: add permissive_hold option to holdtap

[DBendit]

This adds a permissive_hold parameter to HoldTap keys that operates in the same fashion as the QMK option of the same name.

See https://docs.qmk.fm/#/tap_hold?id=permissive-hold

[prokopiff]

Does this really work differently from prefer_hold parameter?

[DBendit]

Does this really work differently from prefer_hold parameter?

Yes, in a way that makes home row mods significantly nicer to use. With prefer_hold, any rollover with a mod key whatsoever triggers the hold key. For example (stealing from the QMK docs):

                         TAPPING_TERM   
  +---------------------------|--------+
  | +-------------+           |        |
  | | LT(2, KC_A) |           |        |
  | +-------------+           |        |
  |       +--------------+    |        |
  |       | KC_L         |    |        |
  |       +--------------+    |        |
  +---------------------------|--------+

With prefer_hold, this will use the layer 2 translation of KC_L, while with permissive_hold, it produces "al".

From my own attempts at using it, prefer_hold is basically unusable with home row mods, since rollovers consistently produce accidental mod activations. I've been using prefer_hold=False, but my tap_time of 180ms meant that, if I was typing quickly, I'd not hold long enough to activate a home row shift fairly often (with QWERTY, this meant trying to type "Oh", and getting "doh" instead). I could lower the tap_time even further, but then I risk accidental activations of the other home row mods I use. I could lower the tap_time of just the shift keys, but then accidental rolling activations are still a concern.

Basically, permissive_hold allows me to get mod activation during holds less than the tap_time if and only if the modified key is tapped and released entirely before the modtap key is released, which is the exact functionality I'm looking for.

Beyond this, I've been wondering if it wouldn't make sense to try and bring holdtap more in line with how QMK does modtap config. Beyond their extensive option set, the community that cares about modtap and home row mods seems entirely built around the configuration language that QMK uses. See https://precondition.github.io/home-row-mods. That conversation is obviously beyond the scope of this change, but the fact that this feature is present in QMK but not KMK is an annoyance that I'm already trying to solve.

[xs5871]

related to #436
Ignoring interrupts from other hold-tap keys is sensible addition and providing a unit-test is also always a good start.
This should be implemented as a seperate option that actually does what it says, not mix, match, and add a little to whats already there.
Call it for example holdtap_interrupted and make it work within the configuration parameters and we should be good.

Feature parity is always good and welcome. Copying QMKs terrible, confusing naming conventions and unintuitive default settings, not so much.