Vim: The extension does not respect vscode's selection

[NOBLES5E]

Environment:

• VSCode Version: 1.12.2
• VsCodeVim Version: 0.8.4
• OS: Linux

What happened:

Using editor.action.smartSelect.grow to selection a string, then press c, it does not modify the whole selected text.

What did you expect to happen: The whole selected text should be modified. (Actually when I selection anything it is expected to enter visual mode. However it remains in normal mode. Even if I enter visual mode manually before executing editor.action.smartSelect.grow, the extension does not respect the selection.)

[LeartS]

I have the same issue, it makes the Expand Select command basically useless; while it's the one I use the most in emacs with evil.

[DrBones]

Same issue for me with Expand Selection, a workaround for me is to press v immediately after the expansion and VS Code's selection turns into VsCodeVim's.

Ideally, for me, VsCodeVim would respect the selection and enter visual mode automatically

[Chillee]

In general, we could handle VSCode triggered visual mode actions better.

We do have a command roughly similar, vaf. It's behavior isn't exactly the same though.

[forsigner]

Same issue with expand-region in Visual mode

[forsigner]

any solutions?

[p-se]

Would entering the visual mode when a selection is made as described in #4034 be a solution to this problem?

[ownself]

I checked out the setting of VSC vim, now mouse dragging leads into visual mode is supported, please support "expand selection" into visual mode!
Or any way to hack?

[stevenguh]

For any brave soul, I think this is where vim handles the selection.

https://github.com/VSCodeVim/Vim/blob/v1.14.5/src/mode/modeHandler.ts#L121

[J-Fields]

I've been playing with our handling of selections recently. Some improvements have been made, but it's still pretty insane. In our defense, it's HARD, mostly because VSCode and vim have fundamentally different understandings of what constitutes a selection, and when A Thing happens to change the selections, VSCode likes to let us infer what happened based on incomplete information.

Anyway, if any brave soul does want to have some fun by poking around this stuff, let me know beforehand.

[berknam]

I've been playing with our handling of selections recently. Some improvements have been made, but it's still pretty insane. In our defense, it's HARD, mostly because VSCode and vim have fundamentally different understandings of what constitutes a selection, and when A Thing happens to change the selections, VSCode likes to let us infer what happened based on incomplete information.

Anyway, if any brave soul does want to have some fun by poking around this stuff, let me know beforehand.

I'm looking into this. If I find anything worth developing I'll post here.

[boyanl]

I checked out the setting of VSC vim, now mouse dragging leads into visual mode is supported, please support "expand selection" into visual mode!
Or any way to hack?

You can hack around it but I didn't find it too simple
Very briefly, with my very limited knowledge of VSCode extensions it involved:
1) Check out the source for this extension
2) Add 2 new commands in this extension for going to normal mode and to visual mode (seemed necessary so they can be called using commands.executeCommand)
3) Add 1 more new command (can be in this extension, or another extension of yours if you have one) that chains the commands "go to normal mode", "expand selection", "go to visual mode"
4) Replace the vscodevim extension with the modified version. (can be as simple as removing the vscodevim folder from ~/.vscode/extensions and making a symlink to the folder with the one you just modified)

This is a very high-level description with no details, but I'm not sure if they are needed. I'm also not sure what would happen if you'd update to a new version of VSCodeVim, but for me, it was easier than changing my typing habits.
Hopefully this can be useful to somebody, and maybe this'll be fixed soon enough so there's no need for hacking around

[ownself]

I checked out the setting of VSC vim, now mouse dragging leads into visual mode is supported, please support "expand selection" into visual mode!
Or any way to hack?

You can hack around it but I didn't find it too simple
Very briefly, with my very limited knowledge of VSCode extensions it involved:

1. Check out the source for this extension
2. Add 2 new commands in this extension for going to normal mode and to visual mode (seemed necessary so they can be called using commands.executeCommand)
3. Add 1 more new command (can be in this extension, or another extension of yours if you have one) that chains the commands "go to normal mode", "expand selection", "go to visual mode"
4. Replace the vscodevim extension with the modified version. (can be as simple as removing the vscodevim folder from ~/.vscode/extensions and making a symlink to the folder with the one you just modified)

This is a very high-level description with no details, but I'm not sure if they are needed. I'm also not sure what would happen if you'd update to a new version of VSCodeVim, but for me, it was easier than changing my typing habits.
Hopefully this can be useful to somebody, and maybe this'll be fixed soon enough so there's no need for hacking around

Thank you bro, I would give it a try :)

[berknam]

I've made a fix for this with PR #5015. Since this change has to be tested manually I would really appreciate someone testing that PR and giving their feedback before it gets merged.

I also found a few other things that I would like to change/fix with selections but since I didn't want the PR to get bloated I didn't put them there. But here are some of the things I think could be done:

The things to note here are:

1. When you select by click and drag the pressed character is always selected even when going back/up (notice that the character 'M' is always selected
2. When you select by click and drag the character is selected as soon as you get the mouse on top of it instead of selecting after you move past the character (you can see this at the end of the gif). This is the behavior of Vim but VSCode only selects a character when you move the cursor to the right of that character which means the mouse will be on top of the next character by then. However as much as I would like to implement this I don't think it will be possible because when doing this as you can see on the gif VSCodes selection doesn't include the last character (you can see that when I select 'handleKeyEvent' the same word 4 lines below doesn't highlight the last character). We could deal with this on the Vim side, but vscode selections would probably always be missing that last character and that visual difference on other occurrences highlight would probably annoy some people.

Note: The changes in this gif are not present on the mentioned PR. Its just some WIP I've been looking into.

[J-Fields]

When you select by click and drag the character is selected as soon as you get the mouse on top of it instead of selecting after you move past the character (you can see this at the end of the gif). This is the behavior of Vim but VSCode only selects a character when you move the cursor to the right of that character which means the mouse will be on top of the next character by then. However as much as I would like to implement this I don't think it will be possible because when doing this as you can see on the gif VSCodes selection doesn't include the last character (you can see that when I select 'handleKeyEvent' the same word 4 lines below doesn't highlight the last character). We could deal with this on the Vim side, but vscode selections would probably always be missing that last character and that visual difference on other occurrences highlight would probably annoy some people.

This is correct - I tried fixing this a few weeks ago and even tried some pretty hacky workarounds but I don't think it's possible without introducing other, more jarring quirks

[berknam]

This is correct - I tried fixing this a few weeks ago and even tried some pretty hacky workarounds but I don't think it's possible without introducing other, more jarring quirks

Yeah I tried forcing the vscode cursor to the right of the character but that made it flicker all over the place. I thought of using a timeout to only correct the vscode selection when the user stopped dragging but that doesn't feel like a good idea either.

The part of keeping the pressed character selected I think it's doable. When I did that I haven't created the lag behind and same selection checks so I was having a few issues with it moving the anchor sometimes. But now with those logics in place it might work better. When I have some time I'll try that and make another PR for that.

[boyanl]

@berknam FWIW it seems to fix the expand selection problem (didn't test much more than that). Thanks!

[stevenguh]

@berknam That's amazing! I tested not exhaustively and it seems to worked well.

I saw that you handled specifically for command type which is for smart grow. I am wondering if you will be able to handle keyboard input as well like changing to visual if a user use shift+arrow. (that has been my pet peeve). I tried to remove the guard for command type in https://github.com/VSCodeVim/Vim/pull/5015/files#diff-a7723f32fe6b05e135838f84e5c23c0fR218, and it seems works somewhat but has some weird issues. I am wondering if you have the capacity to work on that alongside with your bucket of things could be fixed?

Regardless, that PR should also fix #3661.

[berknam]

@berknam That's amazing! I tested not exhaustively and it seems to worked well.

I saw that you handled specifically for command type which is for smart grow. I am wondering if you will be able to handle keyboard input as well like changing to visual if a user use shift+arrow. (that has been my pet peeve). I tried to remove the guard for command type in https://github.com/VSCodeVim/Vim/pull/5015/files#diff-a7723f32fe6b05e135838f84e5c23c0fR218, and it seems works somewhat but has some weird issues. I am wondering if you have the capacity to work on that alongside with your bucket of things could be fixed?

Regardless, that PR should also fix #3661.

I could do that, but that would allow to go to visual mode with shift+arrow when in insert mode which means that then it would also make sense to make click and drag go to visual mode when on insert mode. To be honest I think that is perfectly fine with me! It would be like using mouse=a and keymodel=startsel,stopsel on Vim.

@J-Fields Do you know why the click and drag going to visual mode when on insert mode hasn't been implemented yet? Was there any decision against that? I know there were people asking for a Select mode but Vim allows the mouse selection to put you in visual mode or select mode depending on the settings. So maybe we could make it go to visual mode now and if later someone implements the select mode we can implement Vims settings to allow the user to choose?!

[stevenguh]

I could do that, but that would allow to go to visual mode with shift+arrow when in insert mode which means that then it would also make sense to make click and drag go to visual mode when on insert mode.

That would be amazing. I thought that's what it should have been in the get-go. But I also don't know if there's any prior discussion about the current behavior.

[J-Fields]

Related: #4972

I remember seeing discussion about this at some point, and there was some disagreement about whether it was desirable. Can't find it now... It's probably reasonable to make it go into visual mode, and when someone inevitably complains, we can implement select mode as well.