Multiple line selection breaks when pressing unexpected key

[d11wtq]

Do the following:

Shift-V
jjjj
Ctrl-n
l (L)

The multiple cursors get set on each line as expected, then when you press L, the cursor on the top and bottom lines moves right (as expected), but the others remain "stuck". At this point the cursors aren't working at all and you need to Ctrl-n, ESC to get the editor looking normal again.

[terryma]

This is unexpected. Could you please post the text that you tested this on? Did you press l or L and did you remap the key to something else?

[d11wtq]

I've figured it out. If you try and move beyond the end of the line (i.e. press l too many times) then it breaks. Therefore, by side-effect, if you select multiple lines where any of those lines are blank, the moment you hit l it breaks.

foo
bar
zip
button

Select all the above lines, then press ctrl-n.

Here you can select them and move left/right fine, within 3 characters. If you go beyond the end of the foo, bar or zip lines, however, the plugin breaks as described above.

foo

bar
zip

Now select all of those lines. If you try to move either left or right (h or l) thing break immediately, due to the blank line.

[d11wtq]

This also affects trying to move left of column zero.

[terryma]

Ok, this is briefly mentioned in the Issues section in the README:

Single key commands that do not terminate properly cause unexpected behavior. For example, if the cursor is on the first character in the buffer and 'b' is pressed.

With that said, blank lines should not cause an issue like you described.

Start with cursor on the first line

foo

bar
zip

Vjjj<C-n>l shouldn't cause an issue. Vjjj<C-n>h will cause an issue due to the problem described earlier since the cursor is on f in foo, and pressing h there causes a Vim error. (Turn your terminal bell on and hit h in regular vim's normal mode, it should cause the bell to sound)

To fix this, we need a way to detect that a Vim command terminates successfully. If it doesn't terminate successfully, the function to continue fanning out the user action to all cursor locations is not called, thus causing these 'ghost' cursors to appear.

[terryma]

I just fixed this in the latest release, which brings us to v2.0, finally at a point where I feel like the plugin is stable enough for general usage. Let me know if you still experience this issue. The plugin should inform you now when some input cannot be replayed successfully.

[d11wtq]

Oh, nice. Gonna try this now 👍

[d11wtq]

That sure does work. Good work. Feels a bit weird deliberately moving the cursors to places they shouldn't be going anyway, but it's not exactly a real use case; it's just good it doesn't break now :)

[terryma]

Yep, the change does fix more annoyance than your particular example. All operator pending commands in normal mode like 'd' and 'c' used to break muticursor mode, now they are treated as unterminated commands and display an error. This paves the way for multikey commands to be implemented in the future.

[d11wtq]

Ok, a much more minor issue in relation to this. I can file a separate issue if you want, though this is not really a huge problem at all. If you go past the end of the line, or left of the start of the line, while the plugin doesn't break, it does seem to register a "change" in the undo history.

[terryma]

Could you please open a new issue and describe the steps to repro? I think I know what you mean, it does seem to create a new undo point with no actual change.