Vim: visualModeKeyBindingsNonRecursive and visualModeKeyBindings don't work for first key pressed after visual mode is entered

[insidewhy]

Colemak users remap hjkl to snei (as hjkl are in ridiculous places using our keyboard layout).

Here is a config representing how we remap the n key and can be used to reproduce this issue using the subsequent steps:

"vim.visualModeKeyBindingsNonRecursive": [
  { "before": "n", "after": "j" }
],

With this config if you type vnn the first n acts as if n hasn't been remapped to j and jumps to the "next match". After this n works as expected (so the second n there cause a down movement). I can also do:

v<left-arrow>n and then n will come out fine. So it's only for the very first key-press after visual mode has been entered.

[insidewhy]

BTW this only affects v (lowercase v).

V (uppercase) and ctrl-V support mappings correctly from the first key-press.

[insidewhy]

Since vscodevim 0.13 the mappings are now handled via the visual... config options rather than the other... but the same issue still exists.

[jpoon]

Can you share the configurations you are using?

[jasonkuhrt]

@jpoon here's mine:

    "vim.insertModeKeyBindings": [
        {
            "before": [
                "k",
                "j"
            ],
            "after": [
                "<Esc>"
            ]
        }
    ],
    "vim.visualModeKeyBindings": [
        {
            "before": [
                "<space>"
            ],
            "commands": [
                {
                    "command": "workbench.action.toggleZenMode",
                    "args": []
                }
            ]
        },
        {
            "before": [
                "H"
            ],
            "after": [
                "^"
            ]
        },
        {
            "before": [
                "J"
            ],
            "after": [
                "G"
            ]
        },
        {
            "before": [
                "L"
            ],
            "after": [
                "$"
            ]
        },
        {
            "before": [
                "K"
            ],
            "after": [
                "g",
                "g"
            ]
        },
        {
            "before": [
                "Tab"
            ],
            "after": [
                "%"
            ]
        }
    ],
    "vim.normalModeKeyBindings": [
        {
            "before": [
                "U"
            ],
            "after": [
                "<ctrl+r>",
            ]
        },
        {
            "before": [
                "<space>"
            ],
            "commands": [
                {
                    "command": "workbench.action.toggleZenMode",
                    "args": []
                }
            ]
        },
        {
            "before": [
                "H"
            ],
            "after": [
                "^"
            ]
        },
        {
            "before": [
                "J"
            ],
            "after": [
                "G"
            ]
        },
        {
            "before": [
                "L"
            ],
            "after": [
                "$"
            ]
        },
        {
            "before": [
                "K"
            ],
            "after": [
                "g",
                "g"
            ]
        },
        {
            "before": [
                "tab"
            ],
            "after": [
                "%"
            ]
        }
    ],

[insidewhy]

@jpoon The minimal config to reproduce this is:

"vim.visualModeKeyBindingsNonRecursive": [
  { "before": "n", "after": "j" }
],

then just follow the instructions in the issue description.

[jpoon]

I fixed a couple of issues with the remapper (#3424, #3418), can you retry on the latest release (v1.0.4)? If it still doesn't work, can you share the debug output?

@ohjames: that config is incorrect, it should be a string array.

"vim.visualModeKeyBindingsNonRecursive": [
  { "before": ["n"], "after": ["j"] }
],

With the above configuration, it works. However, we require that the remap matches precisely the keys inputted (https://github.com/VSCodeVim/Vim/blob/master/src/configuration/remapper.ts#L202). IOW, for this to work, you'll need to press: v, then a couple seconds later n

[hioki-daichi]

Although it may not be related, shortening the value of timeout like "vim.timeout": 100 may work.

I defined the following mapping,

  "vim.visualModeKeyBindingsNonRecursive": [
    {
      "before": ["v"],
      "after": ["$", "h"]
    }
  ],

and it did not work well with "vim.timeout": 500, but now it works with "vim.timeout": 100.

Reproduction procedure

1. Set "vim.timeout": 500.
2. Type vv.
   
   
   
   • Contrary to expectation, just visual mode is canceled.
   
   
3. Set "vim.timeout": 100.
4. Type vv.
   
   
   
   • As expected, it is selected to the end.
   
   

[jpoon]

Yep, thanks for pointing that out @hioki-daichi. After doing a bit of research, this seems inline with the behaviour for vanilla vim. If that conclusion is incorrect, let me know.

I think this issue was ultimately resolved with https://github.com/VSCodeVim/Vim/pull/3424 and with https://github.com/VSCodeVim/Vim/pull/3440, I'll be adding some validation around the remap to ensure that a string array is used.

[insidewhy]

I'll check it out, in vim/neovim I can do v followed by n in less than a second and get the remapped n. I'll paste my configs.

I dunno if the string syntax for configs worked or if I made a mistake when I wrote my config out.

[sql-koala]

Hi,
I installed vscodevim these days and the "problem" is still there, as described. When you remap a char in visual mode, it does not work on the first keypress after entering visual mode.
The workaround with timeout is not really feasible, because it practically disables any user defined mapping with two keystrokes (you have no chance to type it fast enough).
However, I have found a workaround by luck. You simply map v to itself in normal Mode and then it works:
{ "before": ["v"], "after": ["v"] },

[insidewhy]

@jpoon this is not inline with vanilla vim/neovim, this issue should not have been closed.

@sqlkoala crazy! Maybe this can lead to a proper fix.

[raphaeltimbo]

Having the same problem. The following works in normal mode but not in visual mode:

{
    "vim.normalModeKeyBindings": [
        {
            "before": ["-"],
            "after": ["$"]
        },
    ],
    "vim.visualModeKeyBindings": [
        {
            "before": ["-"],
            "after": ["$"]
        },
    ],
}

[insidewhy]

I still don't get why this is closed, neovim and vim aren't like this at all.

[slier81]

why is this closed? clearly this bug is not fixed..
i cant remap kj to esc in visual mode

u cant bind to more than one key in visual mode

    "vim.visualModeKeyBindingsNonRecursive": [
        {
            "before": [
                "k",
                "J"
            ],
            "after": [
                "<Esc>"
            ]
        }
    ]

will not work

binding to more than 1 key is normal vim behavior but not this plugin

[insidewhy]

@slier81 It's closed because @jpoon said:

this seems inline with the behaviour for vanilla vim. If that conclusion is incorrect, let me know.

Well it was not inline with vim behaviour and the conclusion was incorrect. We let him know and he didn't reopen the ticket.

[berknam]

@slier81 It's closed because @jpoon said:

this seems inline with the behaviour for vanilla vim. If that conclusion is incorrect, let me know.

Well it was not inline with vim behaviour and the conclusion was incorrect. We let him know and he didn't reopen the ticket.

@insidewhy The problem stated in this issue has been fixed in the last version '1.15.0'.

why is this closed? clearly this bug is not fixed..
i cant remap kj to esc in visual mode

u cant bind to more than one key in visual mode

    "vim.visualModeKeyBindingsNonRecursive": [
        {
            "before": [
                "k",
                "J"
            ],
            "after": [
                "<Esc>"
            ]
        }
    ]

will not work

binding to more than 1 key is normal vim behavior but not this plugin

@slier81 This is a different issue and will be fixed when #4735 gets merged.

[insidewhy]

@insidewhy The problem stated in this issue has been fixed in the last version '1.15.0'.

Thanks for the info. I went back to neovim because there wasn't any way to get this plugin to work well with a colemak keyboard layout, and due to the undo handling bugs. I'll try it again someday.

[berknam]

@insidewhy The problem stated in this issue has been fixed in the last version '1.15.0'.

Thanks for the info. I went back to neovim because there wasn't any way to get this plugin to work well with a colemak keyboard layout, and due to the undo handling bugs. I'll try it again someday.

After PR #4735 gets merged it should be possible to work with colemak keyboards. That PR will also introduce operator-pending mode remaps.

[insidewhy]

@berknam That looks promising, thanks for the info.