vscode-neovim: infinite file opening loop

I applied @seandewar’s patch to the latest release of the plugin, and it works fine as far as I can tell.

If you want to use the plugin without downgrading neovim:

curl -L https://gist.github.com/kidonng/1f70b2e3de50b519483f6c79dd3d82e2/raw/6b865cec34f78475dc50b208b30563d337427543/extension.js > ~/.vscode/extensions/asvetliakov.vscode-neovim-0.0.78/dist/extensions.js

This command writes to a file named extensions.js, but the correct file is extension.js, which means the following is the correct command:

curl -L https://gist.github.com/kidonng/1f70b2e3de50b519483f6c79dd3d82e2/raw/6b865cec34f78475dc50b208b30563d337427543/extension.js > ~/.vscode/extensions/asvetliakov.vscode-neovim-0.0.78/dist/extension.js

How did the original comment get 6 positive reactions (at the time of writing) while having a typo, and thus not working, is beyond me. Nice solution overall though.

Released 0.0.79 with the fix. Thanks @seandewar !

I applied @seandewar’s patch to the latest release of the plugin, and it works fine as far as I can tell.

To use the plugin without downgrading neovim:

curl -L https://gist.github.com/kidonng/1f70b2e3de50b519483f6c79dd3d82e2/raw/6b865cec34f78475dc50b208b30563d337427543/extension.js > ~/.vscode/extensions/asvetliakov.vscode-neovim-0.0.78/dist/extension.js

(Or grab the file from https://gist.github.com/kidonng/1f70b2e3de50b519483f6c79dd3d82e2 and replace dist/extension.js under extension directory manually)

Temporary fix:

git clone https://github.com/neovim/neovim
git checkout 4be0e92db01a502863ac4bb26dd0fee16d833145
make CMAKE_BUILD_TYPE=Release CMAKE_INSTALL_PREFIX=$HOME/nvim
make CMAKE_BUILD_TYPE=Release CMAKE_INSTALL_PREFIX=$HOME/nvim install

Point to <your home directory>/nvim/bin/nvim

https://github.com/neovim/neovim/pull/13664 is cause

@seandewar will it disable autocmd events for buffers? we rely on them for some things - external buffers (like :help) and jumping.

okay i’ve got repro now

My init.vim is empty now and it still seems to be acting up. I will see if there is something I am missing.

This major showstopper bug has been left open for 18 days after a working solution was posted, what is the hold up?

Welcome to the open source.

I’ll push the update soon, sorry for taking it too long and any inconvenience it caused

Glad to see my fix appears to be working. 🎉 Thanks @kidonng and @eyalch for making it easily installable.

I’m happy to open a PR if @asvetliakov is OK with this.

Just to note, if the problematic Nvim patch does get reverted, keeping the fix in shouldn’t cause any issues. I would still recommend reverting the fix after some time once it’s no longer required, though.

will it disable autocmd events for buffers? we rely on them for some things - external buffers (like :help) and jumping.

I can imagine that in most cases (unless there’s some weird event nesting going on) if eventignore is set only for the duration of openWindow(), it can be used to disable the problematic events fired by nvim_open_win() (and nvim_win_set_buf()) only, which may be used to replicate the behaviour before the patch.

You’ll need to remember to restore eventignore after each openWindow() call though.

The main reason this patch is causing issues for people is that BufWinEnter, BufEnter and BufLeave can now fire when they previously couldn’t, among others (BufWinLeave may also cause problems in some other plugins).

For many people, it might be enough to set eventignore=BufWinEnter,BufEnter,BufLeave before openWindow().

Thought I’d experiment a bit with this idea. After making the following changes I wasn’t able to reproduce the issue anymore:

diff --git a/src/buffer_manager.ts b/src/buffer_manager.ts
index 225c499..6bffdff 100644
--- a/src/buffer_manager.ts
+++ b/src/buffer_manager.ts
@@ -553,11 +553,13 @@ export class BufferManager implements Disposable, NeovimRedrawProcessable, Neovi
      */
     private async createNeovimWindow(bufId: number): Promise<number> {
         // eslint-disable-next-line @typescript-eslint/no-explicit-any
+        await this.client.setOption("eventignore", "BufWinEnter,BufEnter,BufLeave");
         const win = await this.client.openWindow(bufId as any, false, {
             external: true,
             width: this.settings.neovimViewportWidth,
             height: this.settings.neovimViewportHeight,
         });
+        await this.client.setOption("eventignore", "");
         if (typeof win === "number") {
             throw new Error(`Unable to create a new neovim window, code: ${win}`);
         }
diff --git a/src/document_change_manager.ts b/src/document_change_manager.ts
index 9895c0a..9eabbde 100644
--- a/src/document_change_manager.ts
+++ b/src/document_change_manager.ts
@@ -248,11 +248,13 @@ export class DocumentChangeManager implements Disposable, NeovimExtensionRequest
             return;
         }
         // create temporary win
+        await this.client.setOption("eventignore", "BufWinEnter,BufEnter,BufLeave");
         const win = await this.client.openWindow(buf, true, {
             external: true,
             width: 100,
             height: 100,
         });
+        await this.client.setOption("eventignore", "");
         if (typeof win === "number") {
             return;
         }

This didn’t seem to break :help or jumping or anything obvious (might be wrong – I don’t use VSC 🤷). Can somebody test this?

Update: A decision was made to revert the patch within a month if there’s no fix upstream, so a workaround may not be necessary soon! 🎉

This is the first time I installed this extension, but due to this issue, it is not useable. I hope this bug gets fixed soon.

git diff view is also broken too. sometimes also happens with ordinary files too

Thanks! Happy to have helped. 🎉

Just a heads up that I’m working on a proper fix upstream at https://github.com/neovim/neovim/pull/14659 (Edit: this has since been merged) that may add a noautocmd option to nvim_open_win to restore the old behaviour.

The eventignore fix will continue to work after that PR is merged so there’s no rush to update things (it may also take a while for openWindow in https://github.com/neovim/node-client to be updated with the new option unless someone volunteers to do it).

@seandewar Awesome, thank you. Subscribed for noautocmd PR. I also might be revisiting window management later (by dropping support of external buffers)

I appreciate your help Alexey! This plugin literally is what makes vscode a viable editor for me.

On Fri, May 28, 2021 at 9:00 AM Alexey Svetliakov @.***> wrote:

This major showstopper bug has been left open for 18 days after a working solution was posted, what is the hold up?

Welcome to the open source.

I’ll push the update soon, sorry for taking it too long and any inconvenience it caused

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/asvetliakov/vscode-neovim/issues/632#issuecomment-850517731, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAAG64TR4U3VNKDKFAY5HPLTP643HANCNFSM44POVTEQ .

–

Fabio Miranda Costa (he/him/his) twitter: @fabiomiranda https://twitter.com/fabiomiranda github: fabiomcosta https://github.com/fabiomcosta/ linkedin: fabiomirandacosta https://www.linkedin.com/in/fabiomirandacosta/

Is it possible that this issue has returned? I’m observing a similar behaviour. An untitled copy of the current file opens at Vscode’s startup. And multiple start to appear when I run a python script on an interactive window. Curiously this only happens when a init.vim file is present. Even a fully commented out init.vim triggers the issue. Deleting or renaming the default init.vim solves the problem.

My specific setup consists on: OS: Windows 10 Visual Studio Code: 1.78.2 Neovim: 0.9.0 or 0.10.0-dev-382-gebb10d624 (I have tried both in case the issue was solved on nightly builds)

Could be something related to Python or Jupyter extensions? I’m working with python scripts via the Microsoft plugins. The extension is great, but dealing with the tab clutter becomes a bit tiresome after a while…

I’m no expert, but imo it should have been reverted ASAP after it was discovered, and then do the fix on unreleased version

One reason for not reverting immediately is at https://github.com/neovim/neovim/pull/14531#issuecomment-838119219.

Breaking changes are to be expected in 0.5, as it is the currently unreleased version.

@seandewar @asvetliakov you people are saviours. Thanks a lot!!

can confirm that the fix is working with vscodium also, thank you.

@eyalch Typo fixed, thanks for spotting it!

Hello, I’m also a new user, and I would like to know if the workaround will be implemented in the VScode plugin and released soon? I will apply the patch on my end, but I suggest it be released asap as well. Thanks.

Also workaround to break the loop: Ctrl-N few times to create new tab(s) then qall!

I think I’ll try to figure out what plugins I need to not initialize, since I do still use some of them, even in visual studio code.