When using j/k to navigate with vscodevim.vim vim extension, it’s pretty laggy. It feels like the FPS is much less than 60 FPS. If I use arrow up/down, it’s ok. The problem is more pronounced in an external monitor.
There seems to be some improvements recently: Vim mode navigation is very laggy - #17 by mohitjain, which makes it better than before, but it’s still laggy in my opinion. VSCode doesn’t have this lag, so i’m not sure where it comes from.
Steps to Reproduce
Install vscodevim.vim, then navigate with j/k. The problem is more pronounced in an external monitor.
Hey, thanks for coming back with an update. I saw thread 138606 fixed the main issue with Cursor Tab request flooding when holding j/k, but based on your report there’s still some residual lag. The note about the external monitor is helpful, we didn’t have that before.
To figure out what’s slowing things down now, a couple quick tests would help:
Compare with Cursor Tab turned off. Settings → Tab → turn off Cursor Tab, restart Cursor, and test holding j/k. If it becomes smooth, the issue is still in the Tab pipeline. If the lag stays, it’s not Tab.
Extension Monitor. Cmd+Shift+P → Developer: Open Extension Monitor (enable it via Settings → Application → Experimental → Extension Monitor Enabled). Please share CPU and memory for vscodevim while holding j/k.
External monitor refresh rate. What’s it set to in System Settings → Displays for that monitor 60Hz / 120Hz / ProMotion? Does it reproduce just as strongly on the built-in MacBook display?
A 10 to 15 sec screen recording showing j/k vs arrow keys in the same file would really help compare FPS.
Once you’ve got that, send it here and I’ll start a follow-up for the residual lag.
Hi, thanks for getting back. To answer your question:
Turning off Cursor Tab doesn’t make a difference
(Attached the screenshot) - the CPU for vim is minimal. But there was an extension host that has 100%, which seems to be from the agent (even though I don’t have any threads running at the moment)
External monitor refresh is at 60Hz. The built-in Macbook display is ProMotion. It doesn’t produce as pronounced in the built-in Macbook display.
I’ve attached the screen recording for cursor (on external monitor) and vscode.
Hey, thanks for the videos. The Drive links are private though, and I’m getting a request access page on all three.
Could you change the sharing to Anyone with the link - Viewer for those files, or just drag and drop the recordings directly into a reply here? Either works.
Hi @deanrie , my apologies for the delayed response. I did not see your message. I re-watched my uploaded videos and thought it wasn’t clear enough distinction between Cursor and VS Code (even though it feels like that using them side-by-side).
I just realized, if I move the cursor using arrow up and down, it’s smooth even on external monitor in Cursor! Only when moving cursor with j/k (vim motion), that it’s laggy. Here is the screen recording:
(I recommend watching the files locally instead of on the preview player in Google Drive. Google Drive seems to compress the quality & reduce FPS in this player). I made sure the permission is set right this time. I think it’s much clearer that arrow key is smoother than vim motion. Hope this helps with the investigation.
Thanks for coming back with updated videos and for the clear isolation. That really helps.
Key point: since disabling Cursor Tab doesn’t change anything, arrow keys are smooth, and the issue is worse on an external 60 Hz monitor than on the built-in ProMotion display, this isn’t the same Tab spam issue that got fixed in the previous thread. This looks like a separate rendering issue specifically on the Vim navigation path that depends on the display refresh rate.
I reported this as a separate follow-up for the remaining lag, with the videos and details attached. I can’t share an ETA for a fix yet, but I’ll post in the thread as soon as I have an update.
A couple quick questions if you don’t mind:
On the external monitor, does the lag change if you set it to 60 Hz vs another mode if it supports it? And does it still happen if you temporarily make the external monitor the main display?
For the extension host stuck at 100% CPU even with no active threads, can you share the Request ID from chat right corner menu > Copy Request ID? I want to check separately whether it’s eating frames.
@deanrie thank you! The external monitor is set as the main display actually. I’m not sure what do you mean by another mode? Do you mean reducing the frequency? (My monitor has 60 Hz as the max frequency).
Interestingly, if I manually map h,j,k,l in the keyboard shortcut to arrow keys:
```
{
“key”: “j”,
“command”: “cursorDown”,
“when”: “vim.mode == ‘Normal’ && vim.active && editorFocus”
},
{
“key”: “k”,
“command”: “cursorUp”,
“when”: “vim.mode == ‘Normal’ && vim.active && editorFocus”
},
{
“key”: “h”,
“command”: “cursorLeft”,
“when”: “vim.mode == ‘Normal’ && vim.active && editorFocus”
},
{
“key”: “l”,
“command”: “cursorRight”,
“when”: “vim.mode == ‘Normal’ && vim.active && editorFocus”
}
```
They are smooth again! So there is definitely something there with Cursor and the vim plugin.
This is a great find, thanks. The fact that remapping h/j/k/l to the native cursorDown/cursorUp/cursorLeft/cursorRight completely removes the lag really narrows it down. It means the issue is in how vscodevim handles cursor movement, not in Cursor rendering itself. I added this to the follow-up about the remaining lag.
A couple of notes:
By “a different mode” I meant refresh rate, but since your monitor tops out at 60 Hz, that’s settled. Thanks for confirming.
This keybinding mapping looks like a solid workaround while we dig in. Based on your description, it behaves the same as j/k in Normal mode.