Add next occurence in insert and normal mode is limited to a maximum of 2 cursors

[RodrigoRoaRodriguez]

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?

Go to either normal or insert mode and press Add next occurence more than two times.
For instance press it four times for the following text (the pipe | represents a cursor)

cursors|[1] = 1
cursors[2] = 2
cursors[3] = 3
cursors[4] = 4

What did you expect to happen?

I expected a new cursor to be added for every press.

cursors|[1] = 1
cursors|[2] = 2
cursors|[3] = 3
cursors|[4] = 4

What happened instead?

Only one new cursor is created, and after that Add next occurrence no longer adds cursors or seems to do anything.

cursors|[1] = 1
cursors|[2] = 2
cursors[3] = 3
cursors[4] = 4

Technical details:

• VSCode Version: 1.10
• VsCodeVim Version: 0.6.13
• OS: OSX 10.11 (El Capitan)

Additional notes

Strangely enough it works on visual mode. Curiously, more than two cursors can be added through other commands such as Select all occurrences or alt-click

The Cmd-d shortcut seems to be disabled by default while in insert mode, however it seems that can be restored by adding "vim.handleKeys": { "<D-d>":false} to your configuration (This however breaks normal mode by limiting it to two cursors).

[johnfn]

This DOES work without making that change to your settings, right?

[RodrigoRoaRodriguez]

@johnfn the change to the configuration is only necessary to trigger _Add next occurrence through the default shortcut (however without it it could still be activated through other means such as the menu item). I will edit the issue to be clearer in this regard so that no further misunderstandings occurs .

[johnfn]

cmd-d works perfectly for me on OSX, no configuration changes required! Do you not experience the same?

[xconverge]

Yea I would not recommend that configuration change since I think we are handling it better for our usage, I was just saying it could be tried

[RodrigoRoaRodriguez]

@johnfn and @xconverge cmd-d does not work for me while I am in insert mode without that configuration change. I tried it in two different computers.

[xconverge]

Yea that should be a separate bug report, should be pretty straightforward!

[RodrigoRoaRodriguez]

I created such an issue before(#1311) for the cmd-d shortcut not working in a previous version of VSCodeVIM. I have updated it to reflect the current state of affairs.

[RodrigoRoaRodriguez]

• VSCode Version: 1.10
• VsCodeVim Version: 0.6.13
  Although undocumented, this seems to have been fixed for normal mode. However, if "vim.handleKeys": { "<D-d>":false} is added to the configuration as a workaround for This extension breaks the Add Next Occurrence command and shortcut #1311 it breaks in the same manner as before.

[jsonMartin]

Saw this issue was closed out but was it fixed?

I still can't use "Add next occurrence" in insert mode, same issue with only selecting two matches in insert mode. It only works in normal/visual mode for me.

[Chillee]

@jsonMartin How are you adding next occurrence? (and have you updated to version 0.7.1?)

The issue you described in the other issue sounds like the exact issue I fixed.

[jsonMartin]

Hey @Chillee, thanks for the quick response!

Yeah, I'm running on version 0.7.1. I'm attaching a copy of the text I posted over in the "multi cursor feedback" thread, but long story short I have tried doing it with my mouse at the menu bar on top of the screen, and with multiple different keyboard shortcuts mapped to "Add Next Occurrence". Also fiddled with the settings, nothing really helped.

Multiple cursors and "Select All Occurrences" work fine in insert mode.

Here's what it looks like when I try it:

[Chillee]

@jsonMartin Can you try <super-d>? I'm having trouble reproducing it. It's weird, since the bug you're reporting is exactly how the old bug looked like.

We should have fixed it in version 0.7.1

[Chillee]

Actually, sorry, I am able to reproduce this. However, I am a little bit about your gif. Are you using a method of adding next occurence that's different from the default keybinding?

The issue happens when the word that you're matching on is also a substring of another word. The thing that's messing it up in your gif is key and licenseKey.

If you have something like

key
key
key
licenseKey
key

it should add cursors up until you get to licenseKey.

The reason is that we can't really handle selections in insert mode (which add next occurrence would usually add). Thus, I had to add my own handling of selections, which I did by just selecting the beginning and end of the word (but it breaks in this example).

[jsonMartin]

Yeah, that's Command + D right? That's what I was actually doing in the demo above to try to select the next matching item.

I have another binding for Add Next Occurrence since Cmd+D was bound to "Duplicate line", but that wasn't working either. I rebound Cmd+D back to Add Next Occurrence to test this, and no change in behavior. Also played around with the "extension.vim_cmd+d" keybindings as well to no avail

[Chillee]

In your case, I think it's the dot right after key. Could you try it on a blank file with nothing after the words?

And definitely open up an issue. This is a bug. :)

[jsonMartin]

OK, so just played around with this more, and learned some additional data points that might help:

• When adding next occurrence via the menu, it only adds two items max no matter what mode it is in (Insert/Normal/Visual). Have to use the keyboard shortcut for it to work properly in any mode.
• Match case option has to be selected to not let the case difference mess up the next selection, otherwise it breaks at the first case difference match.
• If the "Match whole word" option is on, it completely breaks the Add Next Occurrence feature in Normal/Visual mode (makes the cursor go backwards).
• You're also right that the dot right after the key is causing the issue. All occurrences after the dot aren't found (this is something I need quite often as a lot of replacements I do are with the class dot syntax)

Recorded another example here:

I can definitely open up an issue for this. Is there anything else that you can think of that I can do in the meantime, as this is a feature I use all the time? Thanks!

[Chillee]

@jsonMartin Unluckily, I don't think so. I'm not really sure how to fix the first one (and I'm not sure it's worth spending the time to do so, since I doubt people use it much).
I can't reproduce the second one. You're saying you have something like

foo
Foo
foo

and it doesn't work in normal or insert mode? Or do you mean something more like your original example, where you have

key
licenseKey
key

?

The third one is bizarre, I'll have to take a closer look at that one.

I know how to fix the 4th one. I should be able to fix them soon, and we're planning on pushing out a release in a couple days, so you shouldn't have to wait too long.

[Chillee]

Haha. While fixing these bugs, I actually found a bug in the default VSCode functionality.

foo|
foofoo
foo

If you press ctrl-d a couple times, VSCode won't match more than 2 cursors here.

[Chillee]

Alright I fixed the main issues over here: #1748

So when you have time to make an issue, I'll merge the PR.

Actually I'll just make the issue myself.

[jsonMartin]

Awesome, thanks @Chillee! This is why I love this plugin, ya'll are on top of it.

No problem about point #1, if it works with keyboard shortcut and not menu, that's fine with me. I was only using the menu to test.

To answer your question about the second issue, it's like my original example when I have "key" vs "licenseKey". In the GIF I posted above, when I'm in insert mode and using the keyboard shortcut to add additional occurrences, it won't select them all.

If you notice, the first 3 lowercase "key" are selected. Then there are two "licenseKey" entries that are correctly skipped over, and the 4th lowercase "key" is added. But after keeping to hit the shortcut to add more occurrences, no more will be added. Looks like that's because of the period, that breaks all additional matches, when I put a space before the period it continues to match just fine. (This is what I assume your PR fixes)

[jsonMartin]

@Chillee Here's one more data point / issue I uncovered in addition to the dot breaking additional occurrences.

When in Insert Mode and Match Case is OFF, no more occurrences can be added after the first case difference. When case is ON, it proceeds fine past the case difference. It works fine in Normal mode.

Not sure if this particular issue was fixed by your PR, but this example might help illustrate what I'm talking about. If you notice here, when Match case is OFF in Insert Mode it breaks at the first licenseKey and won't add any more after:

[Chillee]

I think the cause is that key is a substring, not that key is uppercase.

For example,

key
licensekey 
key

Doesn't work for me. And neither does

key
keylicense 
key

However, when the key isn't a substring, but there is a case difference, it works.

For example,

key
Key
key

works fine.

[jsonMartin]

Ah @Chillee , you're right! It doesn't matter whether it is uppercase or not, it is based on substring. So if "Match Whole Word" option is on, it will correctly skip "licensekey" or "licenseKey" while in insert mode.

So the problem then is that when I switch back over to normal or visual mode, "match whole word" is causing the cursor to go backwards; this happens when using "gc" command or Add Next Occurrence keyboard shortcut.

However, when I manually highlight the desired word (whether with a mouse, or keyboard) and then add next occurrence (rather than just pressing the shortcut in the middle of the word), it seems to find all the matches OK! The big caveat to this method I'm seeing is that after selecting the matching occurrences and trying to change or delete them, it is removing the character directly to the right (whether that's a space, or a period). To correctly select the whole word in visual/normal mode, the cursor has to be to the right of the word, which is why I believe when multiple cursors are added it's deleting the extra character — the only way I've found around this is that after selecting all occurrences in this mode, to hit the left arrow so it moves the cursor back before changing or deleting. If that doesn't make sense, please let me know and I can show an example.

I assume that the intended behavior is to be able to press the add next occurrence shortcut and cursors should be added in the same positions and edit the same selection of text no matter which mode the user is in.

[Chillee]

@jsonMartin Yep, you're right. I think I've fixed all the bugs on master except for the "whole word" one. I'll need to take another look at that one to figure out how to handle it.

[jsonMartin]

Awesome, thanks for all the hard work on this. Much appreciated, cheers!

[Chillee]

@jsonMartin We just pushed out a new release, so try that and see if that fixes your issues!

Note: We swapped around gc and gb, which matters in normal mode/visual mode.

[jsonMartin]

@Chillee Just checked out the new version, and looks like Insert mode multiple cursors is working perfectly for me now, fantastic! Thank you so much!

I'm still seeing that bug in normal/visual mode on the new version however (which is what I think you mentioned above in your comment about the "whole word" bug). Here's an example of what it looks like on my end just to be clear: