Jumping to Previous Position After Pressing a Key
Describe the bug When searching for a symbol in VS Code, after finding the symbol and navigating to it, pressing any key on the keyboard causes the cursor to jump back to its previous position.
To Reproduce Steps to reproduce the behavior:
- Toggle the search symbol in VS code ( Ctrl + Shift + o ) or (Ctrl + p ) and then type "@"
- start searching for a symbol that you want to go to
- click the symbol or press enter
- start pressing any key
Expected behavior After navigating to the symbol I want to go to, the cursor should not jump back to its previous position after pressing any key.
Environment
- Extension (VsCodeVim) version: v1.27.3
- VSCode version: 1.92.1
- OS: Windows 10 ( Windows_NT x64 10.0.19045)
Additional context This issue is not limited to searching for a symbol. If I also search for a word by pressing (Ctrl + F) and then navigate to that word, pressing any key causes the cursor to jump back to its previous position. This bug does not always occur, sometimes it doesn’t happen, and I’m still unsure what triggers it.
I have the same issue, performance varies in different files, some files must appear, while others do not have this issue。 hope this problem can be resolved soon
gd is used to go to the definition in my config. After press i to enter the insert mode, it jumps back to the previous position.
https://github.com/user-attachments/assets/3deba5bf-2d0a-4698-8832-52f528837fa3
This bug exists for more than a year and was reported here: https://github.com/microsoft/vscode/issues/177598
But it was closed after being identified as related to VSCodeVim.
If there are any pointers or guidance on how to address this, please let me know—I'm happy to contribute if I'm able.
This bug annoys me every single day.
This is because <C-o> uses custom jump list and track jump(goto) command that is issued by vim only. So goto issued by mouse click is not tracked.
To fix this simply add this to settings.json
{
"before": ["<C-o>"],
"commands": [
"workbench.action.navigateBack"
]
},
Hi @qazxcdswe123 I'm slightly confused about where <C-o> come into play.
I'm having this issue with "Go to Definition" (F12) followed by vim cursor moving command (h/j/k/l)
It feels like cursor jumping from VSCode commands are not tracked by VSCodeVim - is it possible to have VSCodeVim somehow find where currently cursor is, in some circumstances, before moving cursors?
Hi @qazxcdswe123 I'm slightly confused about where
<C-o>come into play. I'm having this issue with "Go to Definition" (F12) followed by vim cursor moving command (h/j/k/l)It feels like cursor jumping from VSCode commands are not tracked by VSCodeVim - is it possible to have VSCodeVim somehow find where currently cursor is, in some circumstances, before moving cursors?
- Use CMD+ Mouse click to jump
-
C-owont jump back to the correct location
As of your problem, I have no idea :(
I have met the same issue at times, but it seems to work fine now, except in visual mode.
This is because
<C-o>uses custom jump list and track jump(goto) command that is issued by vim only. So goto issued by mouse click is not tracked. To fix this simply add this to settings.json{ "before": ["<C-o>"], "commands": [ "workbench.action.navigateBack" ] },
In my "vim.handleKeys" setting, "<C-o>" is disabled, but the problem still rises
Experiencing the same issue. After jumping to definition, moving the cursor takes me back to previous location. I will say however, that it only started happening recently, and not in august as the original reporter.
Dear who still suffering from this bug. After I changed vim extension version to 1.28.1 (from 1.29.0) this issue is solved.
Note: I get this only if the definition is in the same file as the original position. If the jump crosses files, then I don't get this issue.
But I don't always get it. I'm not sure what makes it sometimes happen and sometimes not.
Does anyone know a workaround, i.e. a key I can press to get VSCodeVim to register VSCode's current cursor position? At present, I have to reach for the mouse. 🐁
this issue exist for more than 2 years at least, not only ctrl - i/o would trigger it, just normal goToDefinition sometimes can wake this issue up. i've get used to reload the whole editor as a reflection op