Vim: Cursor jumps to position in vertical split after delete

Created on 5 Feb 2019  路  13Comments  路  Source: VSCodeVim/Vim

Describe the bug
If I have the same file open in a vertical split, and the cursor is at another position in the other split, if I hit "j" or "k" to move after deleting, the cursor will jump to the same line as it is in the other split

To Reproduce
Steps to reproduce the behavior:

  1. Open a file
  2. :vs
  3. move to another line in the split with j or k, preferably one off screen to heighten the problem
  4. return to the first buffer and navigate with j or k to a higher line
  5. dd
  6. j or k

Expected behavior
Cursor moves up or down one line normally

Actual behavior cursor jumps

Screenshots
In the following gif, I delete a line with dd, and hit j in an attempt to scroll down.
vsjumpbug

Environment (please complete the following information):

  • Extension (VsCodeVim) version: 1.0.7
  • VSCode version: 1.30.2
  • OS: macOS 10.13.6

Additional context
Add any other context about the problem here.

upstreavscode

Most helpful comment

Another workaround: use gj and gk instead of j and k after the deletion to avoid the jump. I've added the following settings to make this permanent:

    "vim.normalModeKeyBindingsNonRecursive": [
        {
            "before": ["j"],
            "after": ["g", "j"]
        },
        {
            "before": ["k"],
            "after": ["g", "k"]
        }
    ]

I'm curious why the visual line up/down commands don't suffer from the same bug?

Extension (VsCodeVim) version: 1.7.1
VSCode version: 1.33.1

All 13 comments

Seems related to #2688, but that should be fixed in this version, so I'm submitting again.

I can say I've noticed this myself recently too, but with horizontal splits.

Hopefully I'll be able to look at it by this weekend or next, unless someone beats me to the punch.

It's happening to me too. Any quickfix to this?

It's happening to me too. Any quickfix to this?

For future reference, and because I was guilty of this so many times, it's generally encouraged to just pile on the thumbs up on the first comment to say you are also affected by it instead of making a comment.

api access to open editors issue 15178 microsoft vscode 2019-02-24 20-52-37

Oof. Looks like this one could be with us for awhile.

I'm not completely convinced I've fixed the issue via #3539, but I believe I have. If somebody could give it a shot and let me know if that works for them, too, I'd appreciate it.

ouch.. quick splitting of panes in VIM is one of its most useful features... this essentially makes splitting the same file across panes and using one to reference the other chaotic and unpredictable.

It's dealbreaking. I've wasted so much time trying to bring my nvim environment up to snuff because I can't work with it.

If you folks can live with visual selections not working quite properly, the patch in #3539 does seem to fix the issue. Excepting searches within visual selections, it does seem to work, @flowchartsman / @heisian, and if you wanted to help figure out why visual selections aren't working, I can point you at some of my guesses as to where the problem might be arising.

The bug also happens when you hit 'v', 'd' and any key, or 'v', 'x' and any key, or 'J' and any key. I found a workaround. When you delete a line, you can cancel the jumping effect by hitting 'ctrl-]'. A box appear with 'no definition found' and you can move as normal. The thing is, you have to hit 'ctrl-]' each time you delete a line or you join.
Extension (VsCodeVim) version: 1.7.0
VSCode version: 1.33.1
OS: macOS 10.14.4

Another workaround: use gj and gk instead of j and k after the deletion to avoid the jump. I've added the following settings to make this permanent:

    "vim.normalModeKeyBindingsNonRecursive": [
        {
            "before": ["j"],
            "after": ["g", "j"]
        },
        {
            "before": ["k"],
            "after": ["g", "k"]
        }
    ]

I'm curious why the visual line up/down commands don't suffer from the same bug?

Extension (VsCodeVim) version: 1.7.1
VSCode version: 1.33.1

Closing as this should've been fixed by #4074. Let me know if this is still reproducible.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

gerardmrk picture gerardmrk  路  3Comments

cckowin picture cckowin  路  3Comments

lucastheisen picture lucastheisen  路  3Comments

st-schneider picture st-schneider  路  3Comments

WangRongda picture WangRongda  路  3Comments