`whichkey.delay` causes a delay in `SPC SPC` shortcut, others seem to be unaffected

[macintacos]

Bug description

When playing around with the whichkey.delay setting, I noticed that SPC SPC would not get registered, whereas going into a menu and executing a command in there (such as SPC f f) worked fine no matter how fast I executed it. It seems like no matter what, for SPC SPC you have to wait for the full delay before the command will be registered.

It's not clear to me whether or not this is intentional, however because things like SPC f f work as fast as I can type it, I am assuming that this is not intentional.

To Reproduce

1. Set whichkey.delay to 500 (or some larger arbitrary value)
2. Press SPC f f as quickly as you can (faster than the whichkey.delay) to search for some files. Note that the list of files comes up immediately, with no delay.
3. Now, press SPC SPC as quickly as you can (again, faster than the whichkey.delay). Notice how this command doesn't get executed until you wait for the menu to fully render.

Expected behavior

SPC SPC would bring up the command prompt as quickly as SPC f f brings up the list of files to search for.

Screenshots

It's hard to see this in the following recording, but you can see me updating this option from 0 to 500 and notice how I have to wait for the menu to display fully before being allowed to run the SPC SPC command:

https://user-images.githubusercontent.com/8128941/162802312-02773ce7-eee8-40f4-a4d9-8c80721afdc2.mp4

Additional context

Keybindings

My keybindings are far too large to fit into a GitHub issue, but thankfully I keep them backed up here: https://github.com/macintacos/dotfiles/blob/trunk/vscode/keybindings.json

Settings

My settings are available here: https://github.com/macintacos/dotfiles/blob/trunk/vscode/settings.json

System information

The extensions I use are here: https://github.com/macintacos/dotfiles/blob/trunk/backup/vscode-extensions-backup.txt (yes, I know it's a lot, but I don't think the number of extensions I'm using is the problem 🙂 )

Here's my system info, if that matters:

CPUs	Apple M1 Pro (10 x 24)
GPU Status	2d_canvas: enabled canvas_oop_rasterization: disabled_off direct_rendering_display_compositor: disabled_off_ok gpu_compositing: enabled metal: disabled_off multiple_raster_threads: enabled_on oop_rasterization: enabled opengl: enabled_on rasterization: enabled raw_draw: disabled_off_ok skia_renderer: enabled_on video_decode: enabled video_encode: enabled webgl: enabled webgl2: enabled
Load (avg)	9, 7, 7
Memory (System)	32.00GB (0.78GB free)
Process Argv	--crash-reporter-id 07e484e5-ada3-4296-adea-39d6c26a0c7c
Screen Reader	no
VM	0%

[stevenguh]

That's pretty weird. I tried both your settings.json and keybindings.json without install all your extensions. I can't reproduce the issue you mentioned.

[macintacos]

Apologies for the delay here. I think that the issue may be unrelated to the setting itself, it seems to just make it easier to encounter.

I tried using VSCode's "extension bisect" while using the method described here to keep VSpaceCode (and related extensions) enabled, and can still reliably reproduce it. I even disabled every setting from Vim/which-key/vspacecode and can still see it.

The most reliable setup I have is:

• Be in NORMAL mode in VSCodeVim.
• Put your cursor on some text. It doesn't seem to matter what kind of text.
• Press SPC as fast as you can. You'll never seem to get to the "second layer" (meaning, it seems like SPC SPC never activates) until you slow down. If you stop hitting SPC for maybe half a second and hit SPC again, the "second layer" menu finally appears.

[stevenguh]

I tried using VSCode's "extension bisect" while using the method described https://github.com/microsoft/vscode/issues/113568 to keep VSpaceCode (and related extensions) enabled, and can still reliably reproduce it. I even disabled every setting from Vim/which-key/vspacecode and can still see it.

Just double checking. I assume you are bisecting which-key versions?

Apologies for the delay here. I think that the issue may be unrelated to the setting itself, it seems to just make it easier to encounter.

If it is not related to the delay settings, I can only think of a few things:

• Just double checking, do you have this settings off?
• Do you have anything on your system that captures the second SPC?
  • Especially in the screencast you uploaded, I don't see ⎵⎵ instead I saw ⎵
• If second SPC is not recognized, I guess the second SPC is so quick that it is before the menu is rendered. Then logically thinking, maybe your menu somehow is slow to render.
  • Do use something like this, maybe the style is slowing down the rendering?
  • Maybe try the vscode built-in theme?

[macintacos]

I'll look into everything you mentioned, but first thing: the fact that you only see one SPC in the above video is just because of my screen recording software - it only displays one character at a time, so sequential SPC invocations look the same. I'll see if I can record the issue with some other software capturing the keystrokes so that the issue is easier to see.

[stevenguh]

I used https://github.com/keycastr/keycastr and it displays multiple characters at a time. Not sure if this helps.