Vim: <leader> <leader> following exit from insert mode doesn't register when using <space> as leader on OS X

[benzittlau]

Describe the bug
When pressing <leader> <leader> attempting to use easy motion immediately after existing insert mode, the second <leader> cancels the command chain and returns to normal mode. This only happens the first time after existing insert mode, and only happens when using <space> as leader.

To Reproduce
Steps to reproduce the behavior:

1. Create an empty document in VSCode with VIM extension installed and enabled.
2. Enter insert mode, and enter some text
3. Press escape to exit insert mode
4. Press <leader> (the status bar will show --NORMAL-- <leader>
5. Press <leader> again (the status bar will return to --NORMAL--
6. Press <leader><leader> now and it will work as expected.

Expected behavior
Using after exiting insert mode should work the same as normal.

Screenshots

Environment (please complete the following information):

• Extension (VsCodeVim) version: 1.11.2
• VSCode version: 1.39.2
• OS: Mojave (10.14.6 (18G95))

Additional context
If I had to guess this feels like a performance issue. I was disabling extensions to see if I could prevent the issue, and while it didn't prevent the issue, with fewer extensions running it seemed harder to reproduce.

[J-Fields]

Not able to reproduce on Windows 10

[benzittlau]

Based on @J-Fields findings I did some further investigation here, and have not been able to reproduce the issue on OS X either, when using a completely clean VSCode instance.

I'm going to continue to try and observe when I'm seeing this effect and isolate the factors. If I'm able to do that I will update this thread, but I believe with the current understanding it's likely others will also struggle to reproduce (and consequently move towards any kind of resolution).

[J-Fields]

@benzittlau If you want to share your settings, I'm happy to try reproducing again with those.

[benzittlau]

@J-Fields Thanks, appreciate that.

In some immediate testing right now I'm struggling to reproduce this in any configuration, but I imagine that once I stop trying to make it happen and get back into my normal workflows I'll manage to resurface it. (Does have me scratching my head as I was finding it easy to reproduce previously).

I'll update the thread once/if I'm able to figure out a more consistent mechanism for reproduction, even if it's more broad (like using my settings).

[benzittlau]

@J-Fields wondering if you could give me some ideas on what to try next in terms of repro as I'm pretty stuck. This was getting annoying enough that I finally bit the bullet and tried setting up a clone of my existing VSCode setup so I could start tearing things apart aggressively and figure out what the contributing factors are.

What I did:

• Created a directory to store a separate VSCode configuration.
• Ran VScode with: code --extensions-dir ~/code/vscode_debugging/exts --user-data-dir ~/code/vscode_debugging/data .. To initialize the data directory.
• Copied over my extensions into the exts directory, and copied my keybindings.json and settings.json to the appropriate places in the data directory.
• Confirmed my settings, keybinds, and extensions are what I have in my main VSCode configuration when launching VScode using the above command.
• Launched VSCode with this cloned configuration against the same project dir that I was seeing the issue in.

With the above steps, I'm still not able to reproduce the issue. I see the issue consistently with my main VSCode instance (even when restarting it from scratch), but I don't see the issue when I launch with the cloned configuration. It's a difference of being almost 100% consistent in being able to reproduce in the one environment, and never having seen it in the other, even though they are (in theory) direct clones.

Are there any factors I'm missing here that I can try and clone over to see if they introduce the issue? Are there any cache's I should/could be clearing in the main instance to try and bring it closer in state to my new environment?

I'm willing to put the work in to try and figure out what's causing this issue as it's very frustrating for me, but I'm a little at a loss currently about where to go next!

[J-Fields]

I'm not aware of anything that could be a confounding factor - seems like you were pretty thorough!

[nutpeg]

I have a similar problem (macOS Catalina v10.15.2). When trying to use EasyMotion and attempting to press <leader> <leader>, it seems the second press of the <leader> key (which is <space> for me) is ignored, unless I wait at least one second after the first press.

[benzittlau]

@nutpeg I've tried moving my leader key to \, and so far haven't seen the issue yet. As much as it's a hassle to try and relearn my vim muscle memory for a space leader to a different key, I'm suspicious the issue has something to do with using <space> as the leader key. I'd at least be curious to hear if you try a different leader key if you observe the same thing. (It's possible it's just pure luck that I haven't seen it with the new leader, as this issue has been difficult to get consistency for).

[quanbrew]

similar problem (macOS Catalina v10.15.4).

workaround:

{
    "vim.visualModeKeyBindings": [
        { "before": ["<tab>"], "after": ["<Leader>", "<Leader>"] }
    ],
    "vim.normalModeKeyBindings": [
        { "before": ["<tab>"], "after": ["<Leader>", "<Leader>"] }
    }
}

[benzittlau]

@quanbrew Trying that out; seems like it's working so far. Could you explain what the workaround is doing; i.e. why it works?

[benzittlau]

Unfortunately on further use I'm continuing to see the issue, even with that workaround in place, so it doesn't seem to have resolved it for me. I'm going to go back to using \ as a leader key again, as that does appear to be continuing to work reliably. I would really prefer to be using <space> though.

[bphilly96]

I was having this issue on MacOS and seem to have fixed it by going to "System Preferences" -> "Keyboard" -> "Text" and unchecking "Add full stop(period) with double-space".

[benzittlau]

@bphilly96 Omg.... I had no idea that was a thing. I've just changed that setting and put my leader back to <space>, and will see if I see the issue again. Hopefully you found the smoking gun here; it definitely seems likely that you have. Thanks so much for posting your solution here!

[benzittlau]

@bphilly96 I've been using space as my leader for about a week now, and haven't seen the issue happen. At this point I'm pretty confident you found the source of the problem. Thank you!

@J-Fields It sounds like we found what was causing the issue here, and it was unrelated to VSCode or this plugin. As @bphilly96 explains above there's a setting in OS X to add a period following a double space. When used in conjunction with using <space> for leader, this appears to have been causing this issue. I don't really understand why this is a desirable feature, or even worse why it's the default setting to have it enabled, but there it is. I'm going to close this issue.