Vim: otherModesKeyBindings does not work in Visual mode

[DarylPinto]

Is this a BUG REPORT or FEATURE REQUEST? (choose one):
Bug Report

What happened:
Remapping a key in vim.otherModesKeyBindings works in Command mode but not Visual mode

What did you expect to happen:
I expected the key to behave the same in both modes.

How to reproduce it (as minimally and precisely as possible):

"vim.otherModesKeyBindings":  [
        {
            "before": ["s"],
            "after": ["<Nop>"]
        }
]

You'll notice that the key is unbound in Command mode, but still active in Visual mode.

Environment:

• Extension (VsCodeVim) version: 0.12.0
• VSCode version: 1.24.1
• OS version: OSX 10.12.6

[insidewhy]

Since VsCodeVim version 0.13.0 you have to use the visual... and normal... options instead of the other... and the visual... ones seem to not work at all.

[insidewhy]

Think this should be closed in favor of #2233

[dylanscott]

It looks like otherModeKeybindings was renamed normalModeKeybindings in this commit.

This is the second time I've had my keybindings broken by an update and required me to read look through the commit history for this extension to fix them. It's very frustrating. I don't understand why you wouldn't make a change like this in a backwards compatible way that wouldn't break people currently using otherModeKeybindings.

[jpoon]

@dylanscott this was mentioned in our changelog -- https://github.com/VSCodeVim/Vim/blob/master/CHANGELOG.md#v0130-2018-06-18. I also put out a notice on our Slack that this was coming. If you have any ideas on how to better communicate these things, would love to hear suggestions.

We decided not to make it backwards compatible as that setting doesn't really make any sense anymore. If we did make it backwards compatible we would then have remappers for insert, normal, visual, and other, where "other" would mean normal and visual for backwards-compat, and that makes it super confusing.

[jpoon]

What are you trying to accomplish @DarylPinto with that keymapping? You want the s key to just go to a blackhole?

[fungiboletus]

In my use case, I replaced my otherModesKeyBindings array by two identical normalModeKeyBindings and visualModeKeyBindings arrays.

A suggestion for breaking changes could be a small warning appearing one version before the breaking change.

[insidewhy]

It'd be nice if it supported an external vimrc type file where you can use inoremap etc. Would be more flexible and allow parts your config to be shared among other vim plugins that work like this (e.g. IdeaVim, vim itself etc.)

Anyway we're going off track and this should be closed in favour of #2233.

[DarylPinto]

@jpoon The issue I'm having still persists in 0.13.0. However, upon further investigation it appears that the cause of the issue is slightly different than I initially thought.

When using Vintage Mode in Sublime Text or Vi in the MacOS Terminal, pressing v to enter Visual Mode shows -- VISUAL -- in the statusline. However, using VSCodeVim the statusline reads -- VISUAL -- v, implying that the v key was pressed again after entering visual mode. This seems to be the cause of the problem, as moving the caret back and forth such that the statusline no longer says v fixes the problem.

Closing in favour of #2233.

[insidewhy]

Moving the caret back and forth fixes it due to the reasons discussed in #2233.