[Macros] Behavior of detecting key release while postponing

[firngrod]

Say I have a macro bound to shift which does the following:

postponeKeys holdKey leftShift

Say I do the following:

• press shift
• tap a
• release shift

a should intuitively be capitalized, but it's not because the holdKey is terminated before the queue is unrolled.

Solving this is not simple, but it may be doable. Maybe make the key release break the postpone for commands which wait for release, but let the scope live until release unroll from the queue? That would get complex with structures like

ifReleased {
  doStuff
  break
}

Maybe it's not doable, but I wanted to raise the issue anyway.

Maybe the solution is to make a delayUntilPostponedRelease style command which waits for release ignoring the postponed events and errors out if it's called in a postponed scope? Then that command along with pressKey could be used to create any wanted effect explicitly.

I used the simplest macro which demonstrates the issue in the example, and it is in itself a useless macro, but other macros with similar structure may cause issues as well, such as the following triggering secondary on a negative safety margin, which could break the holdKey in the trailing postponed cycle?

ifSecondary holdKey leftShift
else doPrimaryStuff

[firngrod]

Wait, delayUntilPostponedRelease is just delayUntilRelease outside of a postponed scope, so that makes no sense. So we already have the tools to solve the issue, realistically. However, it is cumbersome, so I will leave this story for someone else to think about as well.

Maybe a scope can be marked to no longer postpone, but to not exit until the postponed release is unrolled? That could be used to solve the nested break maybe?

[kareltucek]

Macros_CurrentMacroKeyIsActive from checking local macro postponing state (which does not currently work) to just global postponer state.

Alright, this is concerning. Will check that “soon”.

After examining the code, I have found that the non-postponing logic fails to trigger in nested local scopes. Are there any other scenarios that seem to fail?

Regarding the rest, I think I understand the main point(s), but I need a bit of time to digest it. For the moment I am onto creating some tests and fixing stuff according to current (however flawed) specification.

postponeKeys holdKey leftShift

Are we dealing with a problem that actually exists, or are we dealing with it just to satisfy our inner perfectionists?

(I mean this example is quite controversial since there is no user story behind it.)

[firngrod]

Once macros like the example in #1489 work again, I will reevaluate this thing. Depending on how the logic plays out, I fear that there may still be an issue with ifSecondary specifically with negative safety margins.

Beyond that, I agree that this may not be worth addressing at all, and I will probably close it if my fears with ifSecondary are unfounded.

[kareltucek]

The command ran in ifSecondary should run in a non-postponed context once the ifSecondary is evaluated. (I mean, it should not see itself as the one who causes postponing, so (I think) things should work consistent and correct.)

[kareltucek]

Solving this is not simple, but it may be doable. Maybe make the key release break the postpone for commands which wait for release, but let the scope live until release unroll from the queue? That would get complex with structures like

This is definitely doable, but will probably need introducing some new concepts.

[firngrod]

This is definitely doable, but will probably need introducing some new concepts.

Questioning the value-to-effort ratio is definitely valid.

However, I do have another idea for a new concept: Adding ignorePostponer or something similar to some commands. For example, I have an issue where I want to use ifPlaytime x in a macro, but the key event happened on the postponer, so even if it's the first line of code, and the time from press to release is less than x, it may still evaluate true because time from postponed press til command evaluation is greater than x. An ignorePostponer or similar parameter to make it calculate from actual macro start rather than "historically correct" start would be nice in this case.

[kareltucek]

However, I do have another idea for a new concept: Adding ignorePostponer or something similar to some commands. For example, I have an issue where I want to use ifPlaytime x in a macro, but the key event happened on the postponer, so even if it's the first line of code, and the time from press to release is less than x, it may still evaluate true because time from postponed press til command evaluation is greater than x. An ignorePostponer or similar parameter to make it calculate from actual macro start rather than "historically correct" start would be nice in this case.

In this scenario, isn't the problem actually that postponer is ignored? This is a bug of the retroactive evaluation - it is not computed retroactively.

[firngrod]

In this scenario, isn't the problem actually that postponer is ignored? This is a bug of the retroactive evaluation - it is not computed retroactively.

Naming is hard. But you get the idea. Something similar could be done for ifKeyActive. These would all just make life easier, not really enable new stuff. I can capture time at the start of macro and then test time elapsed myself. I can also combine ifKeyActive with a look through the postponer queue. It would just be a little easier the other way. :)

[kareltucek]

It would be nice if we could push the language toward an easy-to-use, intuitive, domain-specific language, rather than towards just exposing internals towards the users so they can do their whate-basically-is-c-coding from Agent.

In other words, maybe let's talk in terms of user stories and what the ideal syntax should be for them?

[firngrod]

Yeah, for ifPlaytime, I would suggest fromKeyPress (current behavior and default) and fromMacroStart.
I think I'm starting to get my head above water now after the vacation, so I might start working on the key press events soon, then I might do this one afterwards, we'll see.