Cursor location incorrect after redo

• Click thumbs-up 👍 on this issue if you want it!
• Click confused 😕 on this issue if not having it makes VSCodeVim unusable.

The VSCodeVim team prioritizes issues based on reaction count.

Is this a BUG REPORT or FEATURE REQUEST? (choose one):

Environment:

• VSCode Version: Insiders installed just now.
• VsCodeVim Version: Installed from Gallery just now.
• OS: Mac

I have no other plugins installed. I just wanted to test if VSCodeVim faithfully recreated the Vim experience, and the first thing I always try is undo/redo to see if the cursor position is restored correctly. It is not.

What happened:

Create a buffer with the following contents:

aaaaaaaaaaaaaaa

bbbbbbbbbbbbbbbb

cccccccccccccccc

Visually select (capital V) from the aaaa line to the bbbbb line. Then while visually selected hit c for "change". Immediately hit escape after changing nothing. Then hit u for undo then r for redo.

You will see your cursor in the wrong place.

Here is where it is placed:

I changed nothing on the cccc line, and yet after redoing a change the cursor is placed on it. The cursor should always be placed at the start of the redone change.

Would it be possible to automate some tests to make sure the cursor is always where Vim would leave it (in this case, it's not just that it's different than vim but that it makes no sense where the cursor is placed).

How far away are we from being able to use NeoVim directly as the editing logic?

In a comment nearly one year ago, I discuss how hard it is to get cursor positions correct, and I specifically mentioned undo/redo cursor location. Since then there have been some bugs where the location is incorrect, and they were fixed, but it keeps breaking because I think the algorithm is very difficult to get right with all the edge cases. Just using NeoVim is one way to make sure it always feels solid. I'm curious how the maintainers feel about moving forward with the NeoVim approach.

Start by reproducing the visual-select, change, undo, and redo sequence described in the issue. No file or test is named, so trace the undo/redo cursor handling from that scenario; done means the cursor returns to the start of the redone change and automated coverage checks this behavior.