ifDoubletap triggers true when the same macro is run twice from different keys

[firngrod]

What the description says, pretty much. It should only trigger true if it's two runs from the same key.

[firngrod]

Also, I think it should only look back one key action, not the entire macro history.

[kareltucek]

Also, I think it should only look back one key action, not the entire macro history.

I have a feeling there was a reason for this. Can't recall what it was though.

[firngrod]

Probably to allow for usage of Calls and Execs. I feel it might be time to introduce key press history.

[kareltucek]

Maybe yes

[firngrod]

I will investigate solutions soon, because parameterized macros have made this a real issue for me. :p

[firngrod]

Another issue, at least for me, is that ifDoubletap will trigger if the key is triggered twice within the doubletap timeout, even if another key has been pressed in the meantime. If I go bububububububu, that's not a bunch of doubletaps.
The best solution I can think of so far is to introduce a keypress history, and then consult that to find out if there is a doubletap. I think you have expressed reluctance to doing so in the past, @kareltucek. Do you recall any specific reasons?
I can think of a couple of complications with it off the top of my head, but they can mostly be handled by keeping history of both presses and releases.

[kareltucek]

I can't recall that, but I would guess mostly additional complexity, or maybe laziness?

So far we have not needed it and this too can be implemented without it.

[mhantsch]

If you store any history of last press or last release, please store it with a timestamp. Then also provide $timeSinceLastPress or $timeSinceLastRelease to be used in 'fast typing streak detection' for HRM.

[firngrod]

In my mind, the only thing that's a doubletap in when a key is tapped twice without any other key action in between. I don't see how this can be robustly addressed without keeping a log of at least the last 2 key actions (previous press and release, ideally). Even if we do something like mark in macro history what key a macro was run for, and whether it was the initial macro for that key (to account for calls and execs), that still disregards actions from non-macro keys which simply do not show up in this equation at all. The same is true for secondary role keys by the way. If a has a secondary role, if I type aha, that last a registers as doubletap. Incorrectly, in my view, but with the doubletap to primary activation postponed until timeout, it doesn't come up much, since I can still use that shift on a to type ah!.
Ideally, I would store the last two key events, and then on press figure out if it was a doublepress and mark it as such in key state. This of course removes the possibility of individual doubletap trigger times, so one could also store the time since last tap if last tap was same key, then decide if it triggers double tap later. This would eat up a bunch of RAM by expanding key state.
One could also store a slightly longer history, say the last 8-16 events, and then examine that when determining doubletap. This allows for retroactive determination of doubletap for macros which may have tried things like ifSecondary or ifGesture/ifShortcut. I also don't want it too long because of privacy paranoia.

[kareltucek]

There is the interrupt concept. It is used to do exactly that in layer toggles iirc.

What I think would be worth is creating an explicit structure / path that carries press information throughout its lifetime.

Indeed resolving doubletaps directly in the preprocessing phase is definitely a good idea.

[firngrod]

Indeed resolving doubletaps directly in the preprocessing phase is definitely a good idea.

That would only require a maximum history of two press/release events, as doubletap just requires uninterrupted press-release-press from one key. One event could even suffice.

What I think would be worth is creating an explicit structure / path that carries press information throughout its lifetime.

Sounds interesting. Where would it live, and how would memory be managed? I don't know of any other central place for key press data to live than in the KeyState, but I don't know the code all that well yet.
For now, 10 bits would be enough to carry a double-tap interval of up to 1 second, so it would be hard for me to see any cheaper place to put it than in KeyState, unless some sort of dynamically managed map of states to press info, but that gets complex. Also, I don't like doing dynamic memory allocation when working with limited RAM as it makes it hard to estimate how much room is left.

There is the interrupt concept. It is used to do exactly that in layer toggles iirc.

I would have to investigate that. You mean if a key is bound to a layer switch with option to toggle, right?

[kareltucek]

They wouldn't live. They would ba passed on, as they are now, just formalized.

Also, I don't like doing dynamic memory allocation when working with limited RAM as it makes it hard to estimate how much room is left.

Yep, we don't do global dynamic allocation here.

I would have to investigate that. You mean if a key is bound to a layer switch with option to toggle, right?

Yes.

But basically, keep track of the last press and if an "interrupt" comes, invalidate it.

[firngrod]

I think I like the idea of determining the doubletap interval on press and passing it down, as you suggest. I wondered how it would survive until it would be needed, but that would be the responsibility of the code which might need it. Stored in macro state and so on.
I will look into this approach, maybe tonight.

But basically, keep track of the last press and if an "interrupt" comes, invalidate it.

This does solve the basic problem, yes, but I think it's more complex to manage passing otherwise unrelated presses to that code for that purpose, as opposed to the above approach.

[kareltucek]

The lifecycle begins in commitKeyState.

I have made refactors there lately - if you track the keystate-> debounceTimestamp and keystate->activationTimestamp, you will get the entire flow I think.

(I considered creating a new key_press_t structure for it that would contain key_state_t* and the activationTimestamp. I think I didn't do it in the end though.)