Race condition with VSpaceCode comma binding (whichkey.triggerKey) about vscode-which-key HOT 10 CLOSED

But let's open another issue to track it.

Alright - let's continue that part in #39!

from vscode-which-key.

I didn't think user can type faster than the rendering of the QuickPick 😅. This actually was on my mind when deciding different solutions for implementing the shortcut , for major mode.

Anyway, I will implement a solution/fix that won't have this race condition for shortcut to major mode.

from vscode-which-key.

Hehe 😊 I guess when already having the keybinding memorized, and when it happens to be on two separate fingers, that doesn't hold true anymore 😄

Thanks for taking a look, let me know if I can help somehow!

from vscode-which-key.

Let me note that this seems like an issue in generic too - not sure if it's fixable though, and if so, whether I should open a separate issue for it.

If I hit SPC p f quickly, I can see pf being entered into the first QuickPick (before the second one gets displayed), then I end up in the +Project menu rather than the +Find file in project one.

edit: I can see there's some handling for this kind of case here:

and indeed it gets much better when I set whichkey.delay to 1 instead of 0. Maybe that logic should be active in some way even without a delay. I can try contributing a fix, but it might take me a while as I have a lot on my plate with my own projects 🙂

from vscode-which-key.

To solving the race condition of entering second key right after ,, I am thinking to supply initial value instead of simulating a key press after waiting the menu to open. The race condition for the original issue is that the simulated press comes after the key x.

If I hit SPC p f quickly, I can see pf being entered into the first QuickPick (before the second one gets displayed), then I end up in the +Project menu rather than the +Find file in project one.

For this case, it can be adjacent to original issue. But let's open another issue to track it. I think the cause of this is probably because multiple onDidChangeValue events are called before the pervious one has a chance to complete, and the time to finish onDidChangeValue probably also increased by #34. Two attempts in my heads are

1. Have a queue to batch the onDidChangeValue to handle event in sequence. However, probably won't work by itself for the upcoming 1.57 (#34) due to how we modify the input.
2. Change the input handling completely to eliminate modification of the input field.

indeed it gets much better when I set whichkey.delay to 1 instead of 0. Maybe that logic should be active in some way even without a delay

The difference is that

@The-Compiler Wondering what's the version of vscode you are running? Can you also try which-key version v0.8.4 to see if it's any better? Btw, I am also having trouble reproducing the issue on my computer

from vscode-which-key.

FWIW I can still reproduce this one even after downgrading to v0.8.4, using sleep 2 && xdotool type ',x'.

from vscode-which-key.

Thanks for checking in :) This in some sense is easier to fix than #39. We just need to build a proper support to pass in initial keys instead of "simulating" keys pressed with consecutively commands.

from vscode-which-key.

On a second thought, this might be solved with approach outlined in #39 with better input handling (queue).

from vscode-which-key.

Released in v0.10.0. The new implementation should be faster and more robust as it uses a processing queue to handle input change.

It is tested with

sleep 1; xdotool type ,; sleep 0.01; xdotool type x;
# or
sleep 1; xdotool type " "; sleep 0.01; xdotool type mx;

We have to wait for at least 10ms for the UI input to be shown before we can type. That's the limit of what we can do.

from vscode-which-key.

Seems to work beautifully now, at least from what I can see so far. Thanks! 👍

from vscode-which-key.