Performing `workbench.action.openEditorAtIndex1` via VIM keybinding breaks vim-mode

• Click thumbs-up 👍 on this issue if you want it!
• Click confused 😕 on this issue if not having it makes VSCodeVim unusable.

The VSCodeVim team prioritizes issues based on reaction count.

BUG REPORT

Environment:

• VSCode Version: 1.17.2
• VsCodeVim Version: 0.10.2
• OS: macOS High Sierra 10.13.1 Beta (17B46a)

What happened:
Trying a bit to emulate Spacemacs keybindings, I set up a keybinding that would switch to a tab based on the number given, i.e. <leader> w 1 switches to tab 1 like Cmd + 1 does in Atom, Safari etc.

Doing this seems to bring Vim mode into a state where it is stuck, almost like it executed the command and is indefinitely waiting on another keystroke, but stopped picking up any new keys.

What did you expect to happen:
That VSCode would switch to the tab and vim-mode would function as normal.

How to reproduce it:

The configuration below should be enough to reproduce. If not, I also had Atom Keymap installed, but that doesn't seem to cause any issues with any of the other vim commands.

    "vim.otherModesKeyBindingsNonRecursive": [
        {
            "before": [
                "<leader>",
                "w",
                "1"
            ],
            "after": [],
            "commands": [
                {
                    "command": "workbench.action.openEditorAtIndex1",
                    "args": []
                }
            ]
        }
    ]

In the screenshot below, you can see in the status line that I am still in Normal Mode, and you can also see the key strokes <leader>w not displaying the 1 which was also pressed.

Start by reproducing the issue with vim.otherModesKeyBindingsNonRecursive and the workbench.action.openEditorAtIndex1 command, using the supplied w 1 mapping. Trace the keybinding handling entry point and verify that switching to editor tab 1 leaves Vim ready to accept subsequent keystrokes in Normal Mode.