Vim: Unexpected jumping after deleting a line with 'd-d'

[booi-stripe]

Describe the bug
Sometimes, the vim extension gets into a state where using d-d to delete a line causes the cursor to jump seemingly randomly in the file. Subsequent d-d commands continue this behavior until the file is closed and reopened.

To Reproduce
Press d-d to delete a line in an open file. Sometimes, it takes subsequent presses to trigger the bug, e.g. d-d-d to delete 2 lines.

Expected behavior
It should perform as it does in vim and delete the line without moving the cursor.

Environment (please complete the following information):

• Extension (VsCodeVim) version: 1.8.1
• VSCode version: 1.33.1
• OS: 10.14.5

[marcmo]

this is amazingly disturbing... it actually renders the vim extension unusable.
also happening in this environment:

• VSCode Version 1.36.0-insider
• Extension 1.8.1
• OS: MacOS 10.14.5

[zaakn]

I guess it's a bug caused by commits from v1.0.5.

I have tried every version from v1.0.0 to v1.8.1 one by one and found v1.0.4 is fine,
also found that the later the version, the more easily the cursor is faulty.

To Reproduce:
two ways:

1. Open a file in a git repo, take some changing, and restore it by gutter-indicators
2. Open two files into the split editors, take a few of [d-d] action, and move the cursor by arrow keys, and [d-d] again. This way may be more difficult to reproduce, unless the version > v1.0.8.

Environment:

• VSCodeVim version: > v1.0.4
• VSCode version: v1.35.1
• vscode-go(other extensions)
• OS: MacOS 10.14.4

2019.06.27 update:
It’s been 5 days since I used v1.0.4, and its cursor is occasionally fail, I mean it's quite occasional.
In addition, I also found a gopls(https://github.com/golang/go/issues/31937) related problem, but I don't know if it has anything to do with it.

[yiding]

I've noticed that this seems to happen for me when I have a split where both panes are showing the same file, and the cursors are in different locations. The cursor jumps usually results in the cursor in one pane moving to the location of the cursor in the other pane.

[RRikor]

This only happens when working in a :vsplit file. I've noticed this same random behaviour also when pressing to go to normal mode. The cursor always jumps somewhere near the bottom of my file.

It basicly makes :vsplit mode useless to work in.

Vscode:
Version: 1.36.1
Commit: 2213894ea0415ee8c85c5eea0d0ff81ecc191529
Date: 2019-07-08T22:55:08.091Z
Electron: 4.2.5
Chrome: 69.0.3497.128
Node.js: 10.11.0
V8: 6.9.427.31-electron.0
OS: Linux x64 5.0.0-20-generic

Vim:
Version: 1.8.2

[sam-sharps]

I also was encountering this and was about to file an issue before finding this thread. Here are my steps to reproduce and my system information if that helps:

1) Install the VIM emulation plugin.
2) Open two panes open with the same file.
3) Cut a line from the file (dd or Command-X).
4) Try to navigate (arrow keys or hjkl), the cursor will jump to the line above wherever the cursor is in the other pane.

• Extension (VsCodeVim) version: 1.8.2
• VSCode version: 1.36.1
• OS: macOS 10.14.5

I also am attaching a video showing what it looks like.
vscodevim-issue-#3804.mov.zip

[fsteinmetz]

This is quite frustrating indeed. It still happend on:

• vscodevim v1.10.2
• VSCode v1.38.0

At least now I understand that it happens only in :vsplit mode

PS: thumbs up for this awesome and extensive extension! I was amazed to see that even commands like compl-whole-line, text-objects and surround were available 👍

[elgertam]

Affecting me as well. Seems to happen mostly in split mode; will cease for some time if I close all tabs and reopen them.

VS Code:

• Version: 1.38.0
• OS: Darwin x64 18.7.0

vscodevim:

• Version: 1.10.2

[lborgman]

It happens very often to me. It is nearly impossible to use the VIM extension because of this. (Is there any alternative? Is there some fork where someone has fixed this?)

[hexagon6]

It happens very often to me. It is nearly impossible to use the VIM extension because of this. (Is there any alternative? Is there some fork where someone has fixed this?)

It seems some people are on the case in this isse #3713 which I assume is related or the same error.

[J-Fields]

Closing as a duplicate of #3713