Vim: Vim cursor does not move with "Go to Next Problem"

Describe the bug When using the keyboard shortcut for “Go to Next Problem”, the focus and cursor move to the next problem in the file. However, using any vim action starts from where the cursor was last, before the keyboard action.

To Reproduce Steps to reproduce the behavior:

  1. Create a file with linting enabled (I used Python with Pylance language server).
  2. Make a syntax error somewhere down the file
  3. Position cursor in beginning of file
  4. Trigger “Go to Next Problem” keyboard action (by default F8 on my machine).
  5. press l.
  6. The cursor will move to one character after it was before the keyboard action.

Expected behavior The cursor should be one character after the problem that “Go to Next Problem” jumped to.

Screenshots None

Environment (please complete the following information):

  • Extension (VsCodeVim) version: 1.17.1
  • VSCode version: 1.51.1
  • OS: Ubuntu 20.04

Additional context None

As an aside, it would also be nice to have a vim action for “next problem”.

About this issue

  • Original URL
  • State: closed
  • Created 4 years ago
  • Reactions: 6
  • Comments: 22 (1 by maintainers)

Most upvoted comments

The issue still exists. In some circumstances movements get broken: the editor shows the movement for several milliseconds then reverts to the previous position. Movements like “normal mode hjkl”, “jump to next git diff” and “clangd goto definition”. Entering insert mode fixes movements, reopening the editor doesn’t.

In what circumstances does the problem occur?

  1. Every time I open a git diff.
  2. After making several folds (e.g. via normal mode “zM”). Opening the folds via “zR” fixes the problem.

This is an extremely irritating problem which happens all the time (not some corner case), makes normal (the most valuable mode) mode effectively useless in diffs and has been there for the last three years. Please, give it more priority.

I can confirm this issue happens.

Steps to reproduce:

  1. Use vim extension
  2. Use a language server or similar that lets you “go to next error”
  3. Press Shift+Ctrl+P “Go to next Problem (Error, Warning, Info)”
  4. Observe that the view moves to the next problem, and the caret is visually moved to the problem
  5. Press any vim movement command, eg. hjkl
  6. When movement is done, the view and caret pops back to the previous position
Version: 1.63.2
Commit: 899d46d82c4c95423fb7e10e68eba52050e30ba3
Date: 2021-12-15T09:39:46.686Z
Electron: 13.5.2
Chromium: 91.0.4472.164
Node.js: 14.16.0
V8: 9.1.269.39-electron.0
OS: Linux x64 5.11.0-46-generic

This is still happens on v1.18.9 for me as well. Not only for problems, but also when using “Go to symbol”.

I’m using v1.18.9 of the extension (VSC Insiders, commit 93f705ab) and I still observe this problem. The cursor visually appears to move when calling “Go to next problem”, but performing a motion (hjkl) updates the previous location of the cursor.

A similar thing occurs if you choose a problem in the “Problems” tab of the lower panel.

I’m using VsCode 1.86.2 and VSCodeVim 1.27.2, Press Shift+Ctrl+P “Toggle Vim Mode” and Again to work around.

This regressed in 1.18.9. I just tried with 1.18.8 and it works there.

I’ve developed a terrible muscle memory of CLICKING after hitting to to next diagnostic to work around this issue. I’m pretty surprised this has been an issue for this long. I’ve only recently moved to VSCode from Vim proper due to tooling fatigue at work and this has been my number one drawback.

Just FYI: I had this issue and ended up here after searching for what was causing it. Closing the editor for that file (actually multiple editors for that file, not sure if relevant) and re-opening seemed to fix it for now as per others’ experience.

I have this issue when using several pieces of core functionality;

  • Go to error
  • Go to symbol
  • Using gd to go to a definition

Randomly (so it seems) vim will just ignore my new cursor location, and instead move back to the previous position once I do any any action (move around, or go into insert), this is driving me a little crazy

this is back in 1.62.3

This keeps on coming back and it’s driving me crazy. Is there any workaround for this?

Works properly in: v1.21.6 and is broken in v1.21.7. Couldn’t there be some kind of regression test for this?

Confirmed that installing 1.18.8 fixes.

@berknam Would it be possible to re-open this issue?

Hi, check out the latest commits and build it manually, this problem has been fixed a while ago via[#5250]