You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I'm trying to configure the "tap dance" behavior in such a way that it will trigger tapped keys instantly, rather than waiting until "tapping-term-ms" has elapsed; but it doesn't seem to be possible currently. Each subsequent tap should simply produce the next keypress in sequence:
Some examples of usage could include:
Giving ( on the first press, and ) on the second press
Giving q on the first press and u on the second
Enabling sticky shift on the first press, and caps_word on the second
Emitting LC(S) on the first press and LC(Q) on the second one (this is the use case that motivated this feature for me)
Tangentially related to #2042, which could be used to implement this functionality in simple cases. Also a duplicate of #1979, which was prematurely closed despite no resolution being offered.
The text was updated successfully, but these errors were encountered:
haasn
changed the title
Tap dance quick release?
Tap dance instant press?
Oct 3, 2024
I guess #1979 wasn't clear enough about the eager tap behavior given both Joel and I missed the distinction. While this sounds like it can be achieved via a macro with tap+sticky layer, it seems reasonable to me to add it as a flag to tap dance.
I'm trying to configure the "tap dance" behavior in such a way that it will trigger tapped keys instantly, rather than waiting until "tapping-term-ms" has elapsed; but it doesn't seem to be possible currently. Each subsequent tap should simply produce the next keypress in sequence:
Some examples of usage could include:
(
on the first press, and)
on the second pressq
on the first press andu
on the secondLC(S)
on the first press andLC(Q)
on the second one (this is the use case that motivated this feature for me)Tangentially related to #2042, which could be used to implement this functionality in simple cases. Also a duplicate of #1979, which was prematurely closed despite no resolution being offered.
The text was updated successfully, but these errors were encountered: