bug - ifNotReleased, delayUntil, postponer

[kareltucek]

The simple resolver implementation I use is still, for example:

$postponeKeys ifNotReleased ifNotPending 1 goTo @0
$postponeKeys ifPending 1 delayUntil 100
$ifNotReleased ifPending 1 final holdLayer mod
$holdKey a

Unfortunately, I have to report a regression: Today, I flashed 8.6.0.kt1 and all my virtual mods immediately caused high typing interference. I already tried to debug it. By using delayUntil 1000 instead of delayUntil 100 above, I found out that the ifNotReleased logic no longer works: Even if the key has been released long before delayUntil 1000 expires, it still goes to the mod layer, instead of playing back the key press as usual typing. I have now gone back to 8.5.4.kt25 and all my virtual mods immediately started working again robustly. So it must have something to do with 8.6.0.kt1...any idea?

Originally posted by @orthoceros in #24 (comment)

[kareltucek]

I mean, there is some chance that I will want to actually do something about the semantics of resolveSecondary and virtual mods, and in that case the discussion I will have to get through is long enough even without having to filter out these unrelated digressions.

Regarding the problem. Two weeks ago, there has been some discussion which lead me to merging official 8.6.0 release. I wouldn't have released new revision otherwise. When starting up git, I found one forgotten line of code, which I could not clearly remember much about. Just a vague idea that there was a weird glitch regarding postponing conditions which was related to that one variable. I usually commit things right after testing them, so this was weird. Finally, I have concluded that the change was probably intentional fix of the problem which I forgotten to commit, and therefore I have commited it.

So, apart from a bunch of official upstream changes, there is exactly one line of code which has changed. c380246

At the moment, I do not understand why that single line would cause ifNotReleased to stop working. Although I remember changing its semantics slightly at some point - unfortunately I am not sure when and why.

This will need more investigation, which I don't have enough time for at the moment. I will need to find why I did that, what exactly is the result and etc..

[orthoceros]

Sure, no problem. I see. If you build a test version without that line, I could test/confirm on a weekend if/that it is related. (But no hurry from my side; 8.5.4.kt25 works well! I just updated the firmware, because I saw and updated to the new Agent version...)

[kareltucek]

I think I have all info I need atm., I just need to find some time for if ;-).

[kareltucek]

Very sorry for having taken so long.

Well, the thing is that ifReleased by definition reports "postponed" state of the key, unless the macro itself initiates the postponing mode, in which case it reports actual hardware state.

Before c380246, reset of the flag which took care of knowing whether the macro initiated the postponer or not was broken. I.e., when you called postponeKeys at the beginning, it had set the flag to true, and it remained set to true until end of the macro.

After the fix, the ifNotReleased flag reports postponed state of the key, which actually is "not released", because the release had been postponed, and haven't been replayed yet.

Obvious hackfix to the problem is to explicitly wait untill the queue is empty again $ifPending 1 goTo @0.

Of course, this behaviour is not good. Unfortunately (and this is very embarassing), I have difficulty to determine whose fault it actually is - after all, all parties behave according to "specification".