Possible further improvement to doubletap

[firngrod]

This is not meant as an "It must be so!" kind of thing, just a thought:
With doubletap as is is now, if I start spamming a key, every other activation will be registered as a doubletap. All fine and good, but when for instance I'm navigating through something tapping my dual role arrow key, if I then start holding it to doubletap to primary, if I had tapped an uneven number of times, I will not get a doubletap-to-primary activation, which is about half the time.
It is possible in the implementation that I made with global doubletap to not actually "consume" a doubletap every time. Basically, a key will be eligible as a doubletap, but unless it's actually used as a doubletap, it won't block the next tap from being one. That is to say that we could make it so that a key is not used as a doubletap unless something triggers from it, be that primary activation, an ifDoubletap in a macro, or a layer lock in the layer case. The primary effect would, in the immediate term, be that a "spam-to-hold" on secondary role keys would always allow double-tap to primary.

I will do a quick PR soon, unless someone adamantly wants me not to.

[pcooke9]

I apologize for this useless comment, but the term "spam-to-hold" immediately triggered my brain to picture a group of people playing a game of "hot potato" with a tin of potted meat.

Anyway, carry on 😆.

[firngrod]

Really? Upon rereading what I had written, I got a completely different thought about holding spam.

[pcooke9]

I take my role as an ignorant end-user very seriously. Mangling concepts outside of the devs' intended context is kind of my superpower 😉.

Goofing aside, this seems like a welcome extension of the doubletap handling IMO.

[kareltucek]

So basically there are following was of handling them:

1. tap doubletap tap doubletap tap doubletap
2. tap doubletap doubletap doubletap doubletap doubletap
3. tap <offer doubletap if previous wasn't used> <offer doubletap if previous wasn't used> ...

We are currently using 1. You are suggesting implementing 3.

Why not pick 2?

[firngrod]

In the general case, if I doubleclick a shortcut twice on my desktop, I want two instances to open, not three.

However, just for secondary role, I specifically do want the third tap to trigger primary. My branch addresses this by introducing the concept of MultiTap. Take a look at #1501

It has a bug right now, and I want to rename the function, as per the comment, but other than that, that branch does what I want it to.

[kareltucek]

In the general case, if I doubleclick a shortcut twice on my desktop, I want two instances to open, not three.

I am not entirely convinced, but unless more people voice concerns, then I guess I am fine with it.

[firngrod]

I am not entirely convinced, but unless more people voice concerns, then I guess I am fine with it.

I am not making the case that it's objectively the best way to handle it, and maybe I should have phrased it differently. I expect two instances, not 3, because that's the most common case (Windows behavior)