Arrow keys and some other motions don't work as expected in visual select modes

[realh]

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?

If I enter a visual selection mode with v, shift+v or ctrl+v the selected block doesn't extend correctly when I use the arrow keys. Instead, an insert cursor appears. I think what's happening is that it's still moving the insert cursor instead of the selection bound. h, j, k and l keys do extend the selection as expected, so I can work around the problem by rebinding the arrows to those letters in otherModesKeyBindingsNonRecursive. However, I can't fix PageUp and PageDown this way, because Ctrl+F has the same problem, and Ctrl+B isn't equivalent to PageUp even in normal and insert mode.

Technical details:

• VSCode Version: 1.7.1
• VsCodeVim Version: 0.4.1
• OS: Debian

[johnfn]

I can't reproduce this on macos sierra VSCodeVim 0.4.1.

Could it be a Debian thing?? That makes no sense.

[xconverge]

This happens for me on macos sierra. It only happens after some amount of time though and restarting vscode (probably a new modehandler) fixes it.

[yihuaf]

The same observation here. The exact problem appears randomly and restart the VS code would fix it.

[soyuka]

Might this be related?

Go inside parenthesis, do some visual selection inside it and replace vi(c, cursor ends up after parenthesis. It does work with ci(. I also noticed that after movements with the visual selection when you hit c or s the cursor does not end up where it's supposed to. The d behaviour is correct however.

[xconverge]

@soyuka I don't think so, and can you verify with the latest version that vi(c is still putting the cursor in the wrong spot for you? I can't seem to reproduce that

[soyuka]

Nice, my problem has been fixed in latest!

[dasizeman]

I'm also having an issue on Windows with the latest version of vscode and the plugin. I press Shift+v, and the current line highlights, but when I press down arrow the highlight disappears, and any consequent actions such as pressing d will only act on the first line. Similar behavior with normal visual mode (pressing v).

These work fine when hjkl are used for navigation but not when the arrow keys are used.

[romanlarionov]

Still an issue on OS X Sierra.

Attempt of using visual block and pressing down.

[johnfn]

@romanlarionov does it continue to happen after you close and reopen VSCode?

[romanlarionov]

@johnfn Yes. I just tested it again after completely reopening the program.

[johnfn]

@romanlarionov can you paste your settings.json for me?

[johnfn]

Can you also try disabling some other extensions and seeing if that has an effect?

[romanlarionov]

Here is my settings.json:

// Place your settings in this file to overwrite the default settings
{
    "editor.cursorStyle": "block"
}

But I think I found the issue:

The line that starts with var controls is indented with spaces, while every other line is indented with tabs.

[johnfn]

Ahh, excellent detective work @romanlarionov. We actually hid that in there as a way to enforce proper spacing conventions. 😉

In seriousness, does that mimic your experience, @dasizeman?

[romanlarionov]

Haha thanks for that

While we're on the topic, I often use shift+i after initializing visual block to replace blocks of code with the same text.

There are issues with using arrow keys and delete keys during this mode:

[xconverge]

I don't think this has anything to do with lines using spaces. Yes you are seeing an issue but the original post here is related to arrow keys not working but jk working correctly. I am still seeing this where periodically visual line stops working with arrow keys until a restart. During this time jk work properly but arrows do not. Restarting DOES fix the issue for a bit.

[Ashod]

If I ignore the issue and continue editing in insert mode, after entering/leaving Visual Mode a few times it starts working again. It's as if internally the editor/vim state is all wrong, or maybe hits an error while trying to do selection using arrows... but I think it's a state corruption since other commands fail to work as well (/ doesn't enter search mode for example).

[Ashod]

Might be helpful to note that when this happens, any use of the arrows fails. For example d followed by up/down arrow doesn't delete current and prev/next lines, rather it just moves the cursor up/down.

[dasizeman]

What has been described is similar to my experience. When I press

<Shift>+v
<down arrow>
<down arrow>
d 

The following occurs:

So you can see that highlighting is incorrect, as well as what is being considered for the next action (only the first line is deleted rather than all three).

[mattvperry]

I have done some investigation into this issue since it has been bugging me recently.

The 'when' clause that is defined for the <up> and <down> keys contains:
"!suggestWidgetVisible && !suggestWidgetMultipleSuggestions"

Removing these conditionals from the keybinding definition seems to resolve the issue. To be sure, I removed the conditionals from only the <up> key and reproduced the issue in only the down direction.

This would suggest that VSCode's keybinding handler is perhaps doing something incorrectly here but I can't be sure.

Can anyone confirm that this resolves the issues and then follow up with the VSCode team?

[johnfn]

Whoa, very interesting @mattvperry. I had a suspicion that it was something like this, since we don't really special case the arrow keys over hjkl in any way.

[johnfn]

@mattvperry A few things before we file a report (since I have never successfully triggered this problem):

1. Would you mind adding one of either suggestWidgetVisible and suggestWidgetMultipleSuggestions back to see which one is the buggy one?
2. Does opening and closing the suggest widget or the multiple suggestions widget trigger this bug? Or is it more complicated than that?

[johnfn]

@xconverge is such a baller that he went over and fixed this on the VSCode side! microsoft/vscode#16689

Gonna optimistically close this one now. Woo woo! (You may not see the change until the next version of VSCode comes out.)

[xconverge]

Thanks @mattvperry your testing was super helpful and pointed me right towards the fix!

[mattvperry]

Awesome @xconverge ! Glad I could help.