Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

bug: VSCode and Nvim buffers get out of sync + general unwanted behavior #1624

Open
2 of 3 tasks
spacian opened this issue Nov 16, 2023 · 28 comments
Open
2 of 3 tasks
Assignees
Labels
bug Something isn't working manager: document_change

Comments

@spacian
Copy link

spacian commented Nov 16, 2023

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

@spacian spacian added the bug Something isn't working label Nov 16, 2023
@xiyaowong
Copy link
Collaborator

#1618

@spacian
Copy link
Author

spacian commented Nov 27, 2023

I don't think the bug is fully resolved yet (v1.1.4) @xiyaowong . However, it is very specific to the keybinding I described in the original post (which is there to keep indentation after leaving insert mode without typing anything after using 'o').
With these keybindings enabled, the behavior now is the following:

  1. Open a new file.
  2. Press o to insert edit mode on a new line.
  3. Type 'asdf'
  4. Press to delete the last charancter.

Expected behavior:
The file should look like this (* is the cursor position):


asd*

Actual behavior:

*

The full new line is deleted.

This only happens with the remap vim.keymap.set({'n'}, 'o', 'o.<backspace>', {noremap=true}) enabled and only with <c-h>, not with <backspace>. However, even if you use <backspace> and leave insert mode afterwards, the file looks like this:


*asd

You then can't move the cursor with l either because neovim thinks the 2nd line exists, but is empty or so. I don't get the Cursor position outside buffer error though, when I move the cursor to the left with the mouse, not sure what's happening there exactly...

@xiyaowong xiyaowong reopened this Nov 28, 2023
@xiyaowong
Copy link
Collaborator

It would be best to provide a screencast.

@spacian
Copy link
Author

spacian commented Nov 28, 2023

I deactivated everything but the keybinding shown for 'o' from my init.lua. I also have the default ctrl+h binding of vscode deactivated and forward ctrl+h to neovim with the option Ctrl Keys For Insert Mode.

I typed 'asdf', then hit <ctrl+h>. That removed the whole line instead of just the last character.

record4.mp4

Edit2: Not pretty, but it works now I guess.

@spacian
Copy link
Author

spacian commented Nov 28, 2023

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.

record.mp4

@xiyaowong
Copy link
Collaborator

xiyaowong commented Nov 28, 2023

Not sure, I can't reproduce it

Please test this build
vscode-neovim.zip

@spacian
Copy link
Author

spacian commented Nov 28, 2023

With the remap for o I described (and that's shown in the videos) enabled, the bug still persists for me. Removing that rebind 'fixes' the issues, but introduces neovim behavior that I wanted to circumvent (the cursor jumps to the start of the new line created by the default o keybind if insert mode is exited without typing anyting, while the keybinding keeps the indentation).

@spacian
Copy link
Author

spacian commented Nov 29, 2023

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...

@xiyaowong
Copy link
Collaborator

xiyaowong commented Nov 29, 2023

Try vscode-neovim.zip

@spacian
Copy link
Author

spacian commented Nov 29, 2023

Unfortunately, it's still not working :( Thank you so much for trying to fix the issue though! I really appreciate it. Can I do anything to help you reproduce the issue?

I also hoped to narrow the issue further by testing versions, it appears to be introduced with the 1.0.0 release. I'm not sure if that's any help.

The repeat with . issue of the c command I could not reproduce on a different machine with the current release. That might just be on my side on some machine...

@jackvividseats
Copy link

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.

@atticusmatticus
Copy link

atticusmatticus commented Dec 18, 2023

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.

@vlrevolution
Copy link

I am also having a lot of sync issues between vscode and nvim since the latest update.. Which version is the working one now @spacian ?

@vlrevolution
Copy link

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

@spacian
Copy link
Author

spacian commented Dec 19, 2023

I am also having a lot of sync issues between vscode and nvim since the latest update.. Which version is the working one now @spacian ?

I have no issues at all with version 0.9.1.
Alternatively, removing the key bindings I described fixed the issue for me and I can use the current version mostly without problems (other than indentation not staying after pressing escape after o or O).

I.e. the issues I showed only appear when I use the following keybindings for o and O:

-- my_lua_keybindings.lua
vim.keymap.set({'n'}, 'o' , 'o.<backspace>', {noremap=true})
vim.keymap.set({'n'}, 'O', 'O.<backspace>', {noremap=true})

Otherwise, the current version works fine for me. I had an issue with neovim not recognizing new lines in a file once in 1.4, but I couldn't reproduce the issue so far. Might be related, might not be.

@theol0403
Copy link
Member

theol0403 commented Dec 19, 2023

@spacian
I think it's very understandable that binding will mess up the sync, because it's trying to add characters in nvim's insert mode while the ownership of the buffer is handed over to vscode insert mode.

@spacian
Copy link
Author

spacian commented Dec 19, 2023

@theol0403 Oh that was was a misunderstanding on my end, I'm very sorry :( I did not read (when applicable) and I figured I used a clean setup and described exactly what I did to that setup, that would count as 'clean'... That is obviously not the case, because it was not applicable.

Updated the bug, although it probably caused a lot of confusion already <.<

@theol0403
Copy link
Member

It's ok I also didn't notice you provided that binding in your original issue anyway. I'm happy it's not a sync issue by default, but maybe there is a solution still.

@jackvividseats
Copy link

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>")

@spacian
Copy link
Author

spacian commented Jan 9, 2024

@jackvividseats What issues do you encounter exactly? I wanted to try some of your bindings because I didn't know them. For me nvim seems to jump to empty buffers in the background when there is no next or previous buffer to go to anymore. It seems to be exactly 1 empty buffer, you can go further and it wraps around, or you can go back as well. VSCode probably doesn't have the empty buffer, but once it finds the buffers nvim is requesting, everything is working again.

If that's what you're experiencing, it's probably unrelated to what I'm describing and I'd recommend opening another issue or using vscode's workbench.action.openNextRecentlyUsedEditor and workbench.action.openPreviousRecentlyUsedEditor commands (probably not exactly the same behavior, but pretty close).

@jackvividseats
Copy link

@spacian same issues as described above. The cursor visible in vscode is not synced with where it is in neovim. Motions move it to very different places than it should be. I don't have this issue, even when not using window change commands. For whatever reason, the 0.9xx versions don't have this issue (but have some of their own)

@spacian
Copy link
Author

spacian commented Jan 10, 2024

@jackvividseats okay if you have the issue without using :bnext and :bprevious commands, that's a different story. For those specifically I think another issue would be better. I'm using vscode-harpoon myself, never had issues with that. Leaves the LSP and Center commands and I didn't try those. I think it would be very helpful to the developers if you could narrow down what exactly is leading to syncing problems with the buffers. Going through a config, ever so small, is a lot of work and they have a lot to do already.

@Dandarprox
Copy link

This is a very big issue, for me it happens randomly when I accept any completion suggestion from vscode or copilot. Buffers get out of sync, the only way to fix it is to close the buffer and reopen it, which is very annoying. To this point I even stopped using VSCode, I love vim motions, this extension was great but now it is unusable for me :(

@vlrevolution

This comment was marked as duplicate.

@jackvividseats
Copy link

I don't want to jinx it, but I updated neovim with homebrew. While the version that displays when I run nvim -v is the same as before, I no longer run into these issues after the neovim update.

tagging
@Dandarprox @vlrevolution hopefully it helps with your issues.

@vlrevolution
Copy link

vlrevolution commented May 3, 2024 via email

@jackvividseats
Copy link

I just jinxed myself it seems, I think the common thread is when there's errors in the file for a while, when errors aren't in the file for too long, I haven't been getting issues.

@jackvividseats
Copy link

jackvividseats commented May 3, 2024

Here's the file where motions break for me, wondering if anyone can reproduce it. There's a line where motions simply don't work.
The errors are intentional, because certain errors seem to be what break neovim's buffer.

describe('demo', () => {
    const renderFunc = (countryCode: string) => {
    ;asdkflja ads fa sdasd a asdfa sdfasdf // this is the broken line 
djasd;laksdf  sdfasdf asdf asdf asd // this line works like normal
    }

    describe('when in US or Canada', () => {
    fasdflkasdj 
        describe('when in the US', () => {
            it('should return true', () => {
                const { getByTestId } = renderFunc( US)

            })
        })

        describe('when in Canada', () => {
            it('should return true', () => {
                const { getByTestId } = renderFunc( CA)

            })
        })
    })

    describe('when outside of the US or Canada', () => {
        it('should return false', () => {
            // GB = United Kingdom
            const { queryByTestId } = renderFunc( 'GB')

        })
    })
})

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working manager: document_change
Projects
None yet
Development

No branches or pull requests

7 participants