Vim: editor.action.smartSelect.expand doesn't propagate the selection to vim extension in normal mode

[pablospe]

Describe the bug
shift+alt+right (_editor.action.smartSelect.expand_) doesn't propagate the selection to vim extension in normal mode properly

To Reproduce
Steps to reproduce the behavior:

1. Select text with shift+alt+right in normal mode
2. Trying to cut text with c doesn't work

Expected behavior
In 2. I would expect the selection to be cut.

• Extension (VsCodeVim) version: 1.16.0
• VSCode version: 1.47.3
• OS: any

Additional context
Add any other context about the problem here.

[J-Fields]

Duplicate of https://github.com/VSCodeVim/Vim/issues/1806, fixed in master

[berknam]

@J-Fields This specific command is fixed in master but if the user tries to use Shift+arrowKeys or Shift+Home/End that is only fixed on PR #5050.

Also I've just discovered a bug in master related to selection changes with visual mode multicursor that I'm currently trying to fix.

[J-Fields]

Ah, I didn't notice the mention of shift+arrowkeys - yeah that'll be fixed once I get around to reviewing that PR.

Also I've just discovered a bug in master related to selection changes with visual mode multicursor that I'm currently trying to fix.

👍 lmk if you need any input on how that should be handled

[berknam]

👍 lmk if you need any input on how that should be handled

Actually I might need some help. This is quite a tricky situation! Here is the issue:

• When you have multiple cursors in visual or visual line mode you have multiple selections
• Sometimes when moving the cursors vscode will combine some of those selections if the cursors get inside another selection
• Currently our updateView logic sets the selections and checks if they are different from the current ones in the editor to know if it will trigger a selection change event. For example we might set something like this:
  
  
  
  • [1, 5; 4, 5][2, 5; 3, 5] where [1, 5; 4, 5] is the first cursor (from position (1, 5) to position (4, 5)) and [2, 5; 3, 5] is the second cursor (from position (2, 5) to position (3, 5))
  
  
  • Vscode will turn that selection into [1, 5; 4, 5] (although sometimes (usually when moving up) it actually returns [1, 5; 3, 5] and that one I don't understand yet, but it might be related to the same issue and disappear once that one is fixed)
  
  
  • I need to know how vscode combines the selections so that I can combine our selections the same way before setting the editor selections because I need to know if it will trigger a selection change event or not (if the resulting selection is the same as the current one that has been already changed by an action like the foldfix hack, then it won't trigger an event)
  
  

If you happen to know this last part it would be great, if not I'll have to dive deep into vscode source. I think they check if there is an intersect between selections and then create a union of those selections but I'm not sure.

[J-Fields]

Sorry, I thought I responded to this. I'm not sure exactly how VSCode combines selections, but I'm surprised that it seems to be nondeterministic. This is a very annoying case that I'd considered briefly at one point before deciding it was niche enough to not warrant the effort until bigger fish were fried 🙃

[berknam]

Sorry, I thought I responded to this. I'm not sure exactly how VSCode combines selections, but I'm surprised that it seems to be nondeterministic. This is a very annoying case that I'd considered briefly at one point before deciding it was niche enough to not warrant the effort until bigger fish were fried 🙃

I think I've got it working. It pretty much makes a union on intersected ranges. So far from manual tests it seems to work fine, I'm just trying to make a test for this to push a PR. If I can't manage to create a test I'll push it without one.