vscode-neovim: bug: VSCode and Nvim buffers get out of sync + general unwanted behavior

Did you check docs and existing issues?

  • I have read all the vscode-neovim docs
  • I have searched the existing issues of vscode-neovim
  • I can reproduce the issue with an empty init.vim/init.lua and no other vscode extensions (when applicable)

Neovim version (nvim -v)

0.9.0

Operating system/version

Windows 10 - 22H2

Describe the bug

After the update to VSCode Neovim v1.0.1, the buffers of neovim and vscode regularly get out of sync. I think it also happens through stuff like auto formatting, but neovim also manages to do so all by itself.

The remap I added was for a purpose I don’t remember right now, I think it had to do with cursor positions after using ‘o’ or so… but it worked in the last release of the extension, so I’ll use it as an example.

Steps To Reproduce

  1. Add remap to otherwise empty init.lua: vim.keymap.set({'n'}, 'o', 'o.<backspace>', {noremap=true})
  2. Open an empty file, press ‘o’ (the just defined shortcut) to go into insert mode on a new line below, type 2 lines: “asdf” and “jkl;”
  3. press <ctrl+h> (while still in insert mode) to delete the last character

Expected Behavior

I expect the file to look like this afterwards (with * showing the current cursor position):


asdf
jkl*

I should have 3 lines and the last character typed, the ‘;’, should be deleted. The cursor should be at the end of the file.

Instead, the file looks like this:

*
jkl;

There are only 2 lines. The cursor is at the start of the file, the first typed line is removed completely. The second line is still there completely. Additionally, the cursor won’t move with hjkl commands because nvim thinks the file is empty. If I click anywhere on the second line, I get the error nvim_win_set_cursor: Cursor position outside buffer

About this issue

  • Original URL
  • State: open
  • Created 7 months ago
  • Reactions: 1
  • Comments: 24 (2 by maintainers)

Most upvoted comments

I can also confirm on macOS. I’ve tried using the VScode undo buffer instead of Neovim undo tree extension, and turning off all Neovim extensions and nothing has stopped the issue. It is irregular and thus difficult to reproduce but it’s there. I have to reload vscode to access certain lines that, although displayed, seem to be unreachable by the cursor and I also lose entire lines of code out of the blue several times a day. I agree with @jackvividseats that it seems to have started happening in the last month or so, I’ll be trying 0.9x version until this gets resolved. Thanks for the pointer.

I’m happy to send something that could help with the debugging process if need be.

One way I have been able to more regularly recreate this bug is in a markdown document, specifically adding the tick ` character when it autocompletes to be 6 ticks total for a code block. My cursor often can’t access those ticks.

Experiencing the same issue where you cannot move the cursor on some lines, it is just stuck at the beginning of the line a lot of the times and I have to reload VSCode

I can confirm on mac that I’ve had this issue since the 1.0 release. So far I’m back to the 0.9x versions and haven’t had problems so far.

FYI I rolled back to vscode-neovim version 0.9.1 and the custom keybinds are working just fine again. At least I feel like that confirms that it’s a bug and not on my end. Not sure why you can’t reproduce it though…

Another issue I found now is repeating a c command merely repeats the delete part, but does not insert what was typed. E.g. repeating ciwasdf<esc> will only delete words when repeated, not replace the word with asdf. Probably unrelated though…

2nd case: I enter insert mode with the o keybinding again, type asdf, the backspace, then escape to exit insert mode. The cursor jumps to the start of the line and I can’t move left with the l key, which still works on the other line as I showcase afterwards.

https://github.com/vscode-neovim/vscode-neovim/assets/19991231/0072bcfb-24d2-42fe-8572-92be26350d17

to bump this, i don’t have any of the bindings mentioned above, but am still encountering these issues. My keybinds are listed below if that helps.


--Remap space as leader key
keymap("", "<Space>", "<Nop>", opts)
vim.g.mapleader = " "

-- Normal --
-- Better window navigation
keymap("n", "<C-h>", "<C-w>h", opts)
keymap("n", "<C-j>", "<C-w>j", opts)
keymap("n", "<C-k>", "<C-w>k", opts)
keymap("n", "<C-l>", "<C-w>l", opts)

-- Navigate buffers
keymap("n", "<S-l>", ":bnext<CR>", opts)
keymap("n", "<S-h>", ":bprevious<CR>", opts)

-- Clear highlights
keymap("n", "<leader>h", "<cmd>nohlsearch<CR>", opts)

-- Close buffers
keymap("n", "<S-q>", "<cmd>Bdelete!<CR>", opts)

-- Better paste
keymap("v", "p", '"_dP', opts)

-- Visual --
-- Stay in indent mode
keymap("v", "<", "<gv", opts)
keymap("v", ">", ">gv", opts)

-- Comment
keymap("n", "<leader>/", "<cmd>call VSCodeNotify('editor.action.commentLine')<CR>", opts)
keymap("x", "<leader>/", "<cmd>call VSCodeNotify('editor.action.commentLine')<CR>", opts)
keymap("n", "<leader>\\", "<cmd>call VSCodeNotify('editor.action.blockComment')<CR>", opts)
keymap("x", "<leader>\\", "<cmd>call VSCodeNotify('editor.action.blockComment')<CR>", opts)

-- Lsp
keymap("n", "<leader>lf", "<cmd>lua vim.lsp.buf.format{ async = true }<cr>", opts)

-- center screen when doing big movements
vim.keymap.set("n", "J", "mzJ`z")
vim.keymap.set("n", "n", "nzzzv")
vim.keymap.set("n", "N", "Nzzzv")


vim.keymap.set("n", "<leader>ae", "<cmd>call VSCodeNotify('vscode-harpoon.addEditor')<CR>")
vim.keymap.set("n", "<leader>e", "<cmd>call VSCodeNotify('vscode-harpoon.editEditors')<CR>")
vim.keymap.set("n", "<leader>pe", "<cmd>call VSCodeNotify('vscode-harpoon.editorQuickPick')<CR>")

vim.keymap.set("n", "<leader>1", "<cmd>call VSCodeNotify('vscode-harpoon.gotoEditor1')<CR>")
vim.keymap.set("n", "<leader>2", "<cmd>call VSCodeNotify('vscode-harpoon.gotoEditor2')<CR>")
vim.keymap.set("n", "<leader>3", "<cmd>call VSCodeNotify('vscode-harpoon.gotoEditor3')<CR>")
vim.keymap.set("n", "<leader>4", "<cmd>call VSCodeNotify('vscode-harpoon.gotoEditor4')<CR>")
vim.keymap.set("n", "<leader>5", "<cmd>call VSCodeNotify('vscode-harpoon.gotoEditor5')<CR>")
vim.keymap.set("n", "<leader>6", "<cmd>call VSCodeNotify('vscode-harpoon.gotoEditor6')<CR>")
vim.keymap.set("n", "<leader>7", "<cmd>call VSCodeNotify('vscode-harpoon.gotoEditor7')<CR>")
vim.keymap.set("n", "<leader>8", "<cmd>call VSCodeNotify('vscode-harpoon.gotoEditor8')<CR>")
vim.keymap.set("n", "<leader>9", "<cmd>call VSCodeNotify('vscode-harpoon.gotoEditor9')<CR>")

vim.keymap.set("n", "<leader>a1", "<cmd>call VSCodeNotify('vscode-harpoon.addEditor1')<CR>")
vim.keymap.set("n", "<leader>a2", "<cmd>call VSCodeNotify('vscode-harpoon.addEditor2')<CR>")
vim.keymap.set("n", "<leader>a3", "<cmd>call VSCodeNotify('vscode-harpoon.addEditor3')<CR>")
vim.keymap.set("n", "<leader>a4", "<cmd>call VSCodeNotify('vscode-harpoon.addEditor4')<CR>")
vim.keymap.set("n", "<leader>a5", "<cmd>call VSCodeNotify('vscode-harpoon.addEditor5')<CR>")
vim.keymap.set("n", "<leader>a6", "<cmd>call VSCodeNotify('vscode-harpoon.addEditor6')<CR>")
vim.keymap.set("n", "<leader>a7", "<cmd>call VSCodeNotify('vscode-harpoon.addEditor7')<CR>")
vim.keymap.set("n", "<leader>a8", "<cmd>call VSCodeNotify('vscode-harpoon.addEditor8')<CR>")
vim.keymap.set("n", "<leader>a9", "<cmd>call VSCodeNotify('vscode-harpoon.addEditor9')<CR>")

I can also confirm on macOS. I’ve tried using the VScode undo buffer instead of Neovim undo tree extension, and turning off all Neovim extensions and nothing has stopped the issue. It is irregular and thus difficult to reproduce but it’s there. I have to reload vscode to access certain lines that, although displayed, seem to be unreachable by the cursor and I also lose entire lines of code out of the blue several times a day. I agree with @jackvividseats that it seems to have started happening in the last month or so, I’ll be trying 0.9x version until this gets resolved. Thanks for the pointer.

I’m happy to send something that could help with the debugging process if need be.

One way I have been able to more regularly recreate this bug is in a markdown document, specifically adding the tick ` character when it autocompletes to be 6 ticks total for a code block. My cursor often can’t access those ticks.