Deleting a line intermittently screws up the cursor position.

[haberdashPI]

Removing a line of text can lead to unwanted behavior on the next cursor move. This bug occurs unreliably; I cannot yet determine the conditions that lead to the problem. Reloading a window where the error is occurring, or performing the actions in a new, copy of the same file (without reloading) and repeating the same actions fails to reproduce the problem. It appears that there is some per-file state that is causing the problem.

For example:

With the text:

line 1
line 2

....more lines

last line

If i am on line 2 and type "ddk" line 2 will be deleted and the cursor will then jump to the end of the file.

[tcfunk]

This is happening for me as well.

I'll add that once it starts, any combination of dd[hjkl] causes the jump to occur. Reloading the file causes the issue to go away.

[MattMcMurray]

This is happening for me after deleting a line. It's usually dd[jk] that causes it for me. The cursor always flies to the bottom of the file.

Code Version: Version 1.33.1
Extension Version: Version: 1.4.0

[jesaerys]

This also happens to me. I can reproduce it with splits viewing the same file.

For example, I open a vertical split and move the cursor in the right split down to the bottom of the file. Then, I switch back to the left split (still the same file as the right side) and do dd to delete a line near the top of the file. If my very next key press is h, j, l, or ESC (it seems to happen for some other keys, too), then the cursor will jump down to the same position as the cursor on the right side. If I close one of the splits, this behavior resolves immediately.

I've noticed that it only happens when I have splits on the same file; it doesn't happen for me when each split has a different file.

[haberdashPI]

That could be related to my problem, but it sounds a little different: in my case the cursor always jumps to the very bottom of the file (like @MattMcMurray). It is possible in all the cases this has happened that the file has been open in another tab (not currently visible) in another split. I tend to have a lot of splits and tabs open at any moment. I'll check it out when I run into this problem again.

[MikeCongdon1]

I have this issue also. It occurs mostly when running split windows on the same file.
After doing dd any combination hjkl will bounce the cursor in the window that the delete happened to the line adjacent to a different applicable split.

If I have all four splits ---
deleting a line in any of them seems to bounce the cursor to the location of the window in which I had done a delete previously. (this is the case unless the window I'm in is the window I did a delete in last - in which case it's the window of last delete that != current window)

I hope this helps.

[jeffhu1]

I have this issue as well. Like the others said, it seems to be happening with multiple windows open on the same file.

[bongjunj]

I have this issue as well!
I prefer editing a file with a couple of windows splitted vertically. After I delete a line of the file, the other window screws up!

[haberdashPI]

I can confirm that this issue happens for me even when the file is open in only a single vertical split. (But there are splits with other files open). It's possible this occurs during a session that had the file open in multiple splits at some point.

[awave1]

Anyone knows where I can start looking if I want to try and tackle this issue?

[yiding]

Similar issue: #3804

From a quick glance at the code, it seems like the current editor state is tied to an EditorIdentity which is currently computed purely from a pane's file name. This means that multiple splits to the same file might end up sharing data structures and therefore confuse the internal state between panes of the same file.

[mitsuhiko]

This PR improves the EditorIdentity check but causes some regressions with undo: #3539

[J-Fields]

I believe this was fixed with #4074. If anyone is still experiencing this, holler and I'll re-open.