Visualblock Insert Bug

[dylnmc]

Information

VIM version

VIM - Vi IMproved 8.1 (2018 May 18, compiled Mar  3 2019 12:27:49 UTC)
Included patches: 1-991

Operating System: archlinux w updates as of Mon 04 Mar 2019 03:00 UTC

Strange Bug

There seems to be a new bug related to visual-block insertion and this plugin. When visual-block-mode is entered with <c-v> in normal mode, and for example, 8j is pressed to move the cursor down 8 lines, then "visual-block-insert-mode" is entered with I, then some text (such as "foo " is entered), then <esc> is pressed, the cursor ends up on the "proper" line. When j is pressed, however, the cursor jumps to the wrong position. It's as if setpos was called and "curswant" was set properly, but for some reason upon moving the cursor, it uses a different curswant.

I think it may be an issue with the autocmd CursorMoved and using setpos(), but I can't be sure, as it's a tricky little bug, and I am not too knowledgable about the inner working of your plugin. However, when your plugin is disabled, then this bug goes away. I also noticed it in andymass's vim-matchup, for what it is worth. Ale is up-to-date, as well, as Mon 04 Mar 2019 03:00 UTC.

Please see the asciinema below for clarification.

Thanks,
dylnmc/novum

[w0rp]

Calling getcurpos causes the bug, and no that's not a typo. Just another great Vim bug.

[w0rp]

This can't be fixed in ALE. I reported a bug in Vim here: vim/vim#4069

[w0rp]

This bug has been fixed in Vim, but I'll re-open until I can remove some uses for getcurpos() where the curswant value isn't needed, to avoid triggering the bug where we don't need to.

[w0rp]

This should be fixed for older Vim versions now too. The only place where the curswant value for getcurpos() might have been needed is when echoing a message would move the cursor to another line anyway, which is rare.