Sticky keys: retap_cancel

[regicidalplutophage]

An enhancement that makes it possible to release a sticky key by tapping it again -- useful when user only wants to tap a key(KC.LGUI) or simply changes their mind. This behavior is enabled by default.

[xs5871]

I was actually thinking of implementing that functionality myself, so thumbs up from me. Could we brainstorm the name a bit? How about something like tap-cancel or retap-cancel or double-tap-cancel? I'd prefer "cancel" because it cancels an action/state, a "release" is something the user does, usually. What is your opinion on canceling all stacked sticky keys instead of just the one that is tapped? Also: unit tests. I don't want to merge unless we have those, because otherwise we'll forget. You don't have to do them yourself, I can contribute those.

[regicidalplutophage]

I like retap-cancel. Cancelling all sticky keys via a sticky key just doesn't feel right. Maybe a special key? I could see an argument for refreshing the timeout of remaining sticky keys.

Maybe we should instead make it "retap_override" which would optionally replace the second tap with any other keycode, including the non-sticky version of the original or None to retain the current functionality? This would also beg for functionality analogous to ZMK's lazy sticky keys when modifier is only sent right before the interrupting key. Though that gets pretty complex and starts toeing tapdance territory. Besides, I'm not sure what I'd use this for, because it wouldn't work for mods as I also need those to interact with a pointing device.

[xs5871]

Good. I would agree on the cancel scope, just wanted to spitball. Unless someone asks for a cancel-all key, I don't think we need it, and I would consider it a waste of space on a low key count keyboard (but I definitely value the suggestion). As for the timeout refresh: I'll leave that to you. Maybe test with what you've got now and decide later. I'm good with incremental improvements to ergonomics.

I don't know how usefull an override mechanic would be in practice. It does sound almost like it could be implemented with a tapdance. I also don't quite get the use case behind ZMKs lazy stickies. It's almost as if stickies started out as a special case of hold-tap, then changed the default to immediately resolve the key instead of delaying until interrupted, and the old behavior stuck around as "lazy".

[regicidalplutophage]

Oh, that reminds me: I haven't tested retap cancel with defer release(I just did now, it works completely as expected) Do you want to add test case for that as well?

[xs5871]

Since the tests succeeded both with and without retap_cancel=True as default I didn't think of that. Doesn't hurt to check though.

[regicidalplutophage]

Thanks!