Vim: Three-letter otherModesKeyBindingsNonRecursive remappings fail to match

Created on 10 Dec 2016  路  5Comments  路  Source: VSCodeVim/Vim

Please thumbs-up 馃憤 this issue if it personally affects you! You can do this by clicking on the emoji-face on the top right of this post. Issues with more thumbs-up will be prioritized.


What did you do?

Added remapping with three letters, like:

  "vim.otherModesKeyBindingsNonRecursive": [
    {
      "before": [ "<leader>", "f", "s" ],
      "after": [],
      "commands": [{
        "command": "workbench.action.files.save",
        "args": []
      }]
    },
    {
      // Just some random letters to make sure it wasn't a problem with the leader key
      "before": [ "g", "y", "z" ],
      "after": [],
      "commands": [{
        "command": "workbench.action.quickOpen",
        "args": []
      }]
    }
  ]

Then pressed the key combination

What did you expect to happen?

The command to run.

What happened instead?

The third letter's command (s in the case of <leader>fs) runs.

Also, when I press the first letter, it appears in the status line. But when I press the second letter, the status line goes back to blank.

If I change the remapping to two characters, it works as expected.

Technical details:

  • VSCode Version: 1.7.2
  • VsCodeVim Version: 0.4.9, also tried master
  • OS: Windows 10

I tried tracing the problem with the debugger, but other than seeing that Remapper.sendKey doesn't find a remapping in the three-character case, I couldn't figure out what was up. If someone has a better idea of where to look, I'd be happy to dig into it further. I think this is related to why "<space>", "f", "s" doesn't work in https://github.com/VSCodeVim/Vim/issues/1132.

Most helpful comment

I have the same issue when I remap ZZ to 'save and close'. My settings.json:

 "vim.otherModesKeyBindingsNonRecursive": [
        {
            "before": ["Z", "Z"],
            "after": [],
            "commands": [
                {
                    "command": "workbench.action.files.save",
                    "args": []
                },
                {
                    "command": "workbench.action.closeActiveEditor",
                    "args": []
                }
            ]
        }
    ]

While analyzing the problem using the debugger I found out that the handleKeyEventHelper method in modeHandler.tsclears the recordedState like this:

    if (result === KeypressState.NoPossibleMatch) {
      vimState.recordedState = new RecordedState();
      vimState.recordedState.commandList = []

Since Z is not a possible match on a vim action, the sendKey method of remapper.ts will always receive just one Z. I think it should be fixed in the handleKeyEventHelper method of modeHandler.ts, we should not only check if there's a possible match against the known vim actions, but also check if there's a possible match against the configured keymappings. I'll try to make a PR for this issue soon, but first I'll check out the contribution guidelines 馃槃

All 5 comments

I have the same issue when I remap ZZ to 'save and close'. My settings.json:

 "vim.otherModesKeyBindingsNonRecursive": [
        {
            "before": ["Z", "Z"],
            "after": [],
            "commands": [
                {
                    "command": "workbench.action.files.save",
                    "args": []
                },
                {
                    "command": "workbench.action.closeActiveEditor",
                    "args": []
                }
            ]
        }
    ]

While analyzing the problem using the debugger I found out that the handleKeyEventHelper method in modeHandler.tsclears the recordedState like this:

    if (result === KeypressState.NoPossibleMatch) {
      vimState.recordedState = new RecordedState();
      vimState.recordedState.commandList = []

Since Z is not a possible match on a vim action, the sendKey method of remapper.ts will always receive just one Z. I think it should be fixed in the handleKeyEventHelper method of modeHandler.ts, we should not only check if there's a possible match against the known vim actions, but also check if there's a possible match against the configured keymappings. I'll try to make a PR for this issue soon, but first I'll check out the contribution guidelines 馃槃

@henkhouwaard Yes, that is EXACTLY why this bug happens. Thanks for investigating! I'd be happy to merge in a PR, this one has been annoying me.

Just ran into this same thing... my muscle memory needs those leader+key+key commands back! Has anyone gotten around to starting a branch/PR for this yet?

I will get to it right now :)

On 0.6.6 three letter bindings don't work again. Something like <leader> q q behaves like <leader> q followed by q.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

cckowin picture cckowin  路  3Comments

jaredly picture jaredly  路  3Comments

triztian picture triztian  路  3Comments

ghost picture ghost  路  3Comments

typeoneerror picture typeoneerror  路  3Comments