Vim: Keep the cursor where it is when entering Visual Line mode.

[c10b10]

By moving it to the beginning of the line, it cannot be matched by typing "%".

[Chillee]

This is unluckily a vscode limitation. However, what do you mean by "cannot be matched by typing '%'"?

[net]

Is there an issue for this on VSCode?

[Chillee]

@net I haven't bothered because it seems like such a long shot. The fundamental issue is that VSCode (and pretty much all editors aside from Vim) don't support the concept of having a selection that has a start, stop, and cursor position. The stop position is also implicitly the cursor position.

[net]

@Chillee Possibly we could track the cursor internally in the plugin and display a "fake" cursor at the proper location. VSCode has a hidden cursor style we could apply to the real cursor. When existing visual mode, we would move the real cursor to the proper location. I'm not sure if it's possible to display a cursor inside a selection though. VSCode already does supports displaying multiple cursors.

[Chillee]

@net I'm looking into doing something like that just to fix our selection off by one issues, but I'm not sure I want to do that for all of visual mode, for a couple reasons.

1. It doesn't fix all of our issues related to this. For example, people complaining about the focus getting shifted to the end of the line will still have the same issue.

2. It seems like a large pain for not that much gain. <--- This is the larger reason.

[net]

@Chillee

It doesn't fix all of our issues related to this. For example, people complaining about the focus getting shifted to the end of the line will still have the same issue.

Not if we track the inline cursor position and move the real cursor there when existing visual mode, no? Visuals aside, having the cursor move to the beginning/end of the selection whenever using visual-line mode has been a real pain for me (I may be alone on this though). Given the frequent use of visual-line mode, it's one of the larger inconsistencies between VSCodeVim and Vim.

[Chillee]

@net I'm reading over some of my comments and I apologize for how unclear I'm being in some places; I'm a little bit preoccupied currently.

That being said, the specific issue I meant was this one: https://github.com/VSCodeVim/Vim/issues/1048

[Chillee]

@net You said that VSCode has a hidden cursor style? Could you provide a link to some documentation or some examples?

[net]

@Chillee Hmm, I must've misremembered. Sorry. 😕

[Chillee]

@net Actually, it's not really the hidden cursor that's the hard part. It's displaying the "fake" cursor position that's annoying. We could use a decoration (like we do in visual block mode), but that looks very bad in my opinion.

[net]

@Chillee

We could use a decoration (like we do in visual block mode), but that looks very bad in my opinion.

Agreed. If the issue is that we can't arbitrarily place and hide cursors, then I'll open an issue on VSCode. Not sure how fruitful it will be, but it's worth a shot. Better cursor control would be great for vim emulation (and possibly other extensions as well).

[matled]

I came across this issue as I ran into the same problem as the original author. As the original report is quite short, I'll add a short summary to make clear what this feature request is about and what the use case is:

When entering visual line mode in vim, the cursor stays at the same position and can still be moved within the line. vscodevim does not support the cursor movement, and uses an inconsistent cursor position for parantheses matching performed with % (see below for examples).

This feature is particularly useful to select a bunch of lines between two parantheses: V%. This is a very common key combination I use to quickly select code blocks in C-style languages. This is somewhat similar to what vscode provides through editor.action.smartSelect.grow.

While playing around with the use of % in visual line mode, I found that the indicated cursor position, and the character used for % matching is not not obvious:

1. after V the cursor is on the first character, but the last character is used for % matching
2. after V and moving down, the cursor is after the last character, but the last character is used for % matching
3. after V and moving up, the cursor is on the first character and the first character is actually used for % matching (this may be surprising after observing the previous two examples)

In addition, I found that pressing % after selecting multiple lines, when % does not match a parantheses, the selection is reduced to only the current line.

In case it is useful to anyone investigating this issue, I used this text to test the behavior described above.

[mbroadhead]

This is unluckily a vscode limitation. However, what do you mean by "cannot be matched by typing '%'"?

Quite often in vim I enter visual mode and then type '%' to match a tag or bracket block. This selects the whole block/tag. When the cursor changes to the beginning of line in vscode visual mode, typing '%' won't match the enclosing tag.

[J-Fields]

Fixed in e5c0a94dced29c336c8f4ab4a611810b286672e5, released in 1.14.2