Strange visual selection with keys remapped to ^ and $

[TomNaessens]

• 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.

---

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

Environment:

• VSCode Version: 1.13.0
• VsCodeVim Version: 0.8.5
• OS: Windows 10, creators update

What happened: In my config, in otherModesKeyBindingsNonRecursive I mapped H to ^ and L to $. When I enter viasual mode (press v) and press L afterwards, it selected to the end of the visible screen. Same for H which selects to the start of the visible screen.

When I press v and then ^ or $, the correct action happens: it selects until the start or the end of the line.

What did you expect to happen: I expect that when I enter visual mode (press v) and press L afterwards, it selects to the end of line. Same for H which I expected to select to the beginning of the line.

How to reproduce it:

1. Add the following to your settings:

    "vim.otherModesKeyBindingsNonRecursive": [
        {
            "before": ["H"],
            "after": ["^"]
        },
        {
            "before": ["L"],
            "after": ["$"]
        }
    ],

2. Enter visual mode: press v
3. Press H (or L)

Important: This worked fine for a few months until it stopped a few weeks ago. I went trough the changelog and the only thing that could be related is the Fixes visual block mode respect keybindings @Chillee #1709 in the Neovim Nutty release. But I'm not sure. Outside of visual mode (in normal mode for example), the work as expected.

It gets even stranger: When I enter visual mode, press a navigation key (e.g. l) once to move one space and then press L, it selects as expected until the end of the line.

[Chillee]

Huh. You're right.

When I first saw this bug report, I thought it was just a limitation of our remapper (for example, dH with that mapping has never worked properly). But I just checked it on a v0.7.0, and it seems to work fine.

How interesting. I personally use this keybinding, so I'll try to figure out what's wrong soon.

[Chillee]

Ok, so this is a bug that was revealed as the result of fixing another bug.

cbcc982

is the commit that caused it.

[benjaminwood]

I too have been impacted by this bug. In my case I had remapped hjkl to jkl;. Same symptom though, switch to visual mode and the remappings do not take effect until at least one key has been pressed.

[jwmann]

I have this same exact issue.

Except since vim.otherModesKeyBindingsNonRecursive was removed, it's more like this:

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

[uri]

These bindings seem to work if you pause for 2-3 seconds after entering visual mode.

With

{
            "before": ["H"],
            "after": ["^"]
}

v pause for 3 seconds H produces the the correct behavior

[charlietran]

I'm still experiencing this bug, but this workaround from #2842 fixes it for now:

  "vim.normalModeKeyBindings": [
    ...
    {
      "before": ["v"],
      "after": ["v", "l", "h"]
    }
    ...
]

[jakalada]

I change Vim Configuration > Timout to 0, This issue is solved. But, it is not a good solution.

[thisisrandy]

Any movement on this? The workaround that @charlietran references breaks text object motions, e.g. viw, so it isn't really viable