(This is a feature suggestion, not a bug report or a request for help.)

I have VSCode installed via linux on a flatpak. Because of sandboxing issues, VSCode can't access my computer's installed neovim installation at /usr/bin/nvim. This headache, as well as many others (accessing it in WSL, having to install neovim separately, having to manually check that you're at least version 0.5, etc) would be solved if the extension bundled its own working installation of neovim.

Benefits:

• It just works.

Downsides to doing this:

• Bigger download size. My nvim executable is 4.3M, and I don't know how big shared libraries will be.
• Not customizable. If somebody wants to run their own custom-compiled version of neovim, they also have to have a custom version of the extension.
• Delays neovim updates. If neovim has a security vulnerability and releases a new version upstream, then the extension also needs to release a new version.
• Might have problems being cross platform? Is it possible to include different executables for each target OS/architecture? I don't know enough about how extensions are published to answer this.

Alternatives:

• Better documentation about common troubles people have with accessing their neovim installations.

---

More detail about my specific sandboxing issues

Just so people can find this page in searches and learn from my pain, not because it's important for this feature request.

My versions and stuff: Linux 5.17.5 PopOS! 22.04 VSCodium version 1.67.2 (A non-telemetry flatpak repackaging of VSCode) VSCode Neovim v0.0.85

When I set "vscode-neovim.neovimExecutablePaths.linux": "/usr/bin/nvim" and vscode can't find the executable, I get popups saying:

MainController: Neovim exited with code: -2
MainController: Neovim was disconnected
MainController: Neovim spawn error: spawn /usr/bin/nvim ENOENT
Source: VSCode Neovim (Extension)

I set my flatpak permissions to --filesystem=host-os (easiest via flatseal, though this step might not be necessary), and set "vscode-neovim.neovimExecutablePaths.linux": "/run/host/usr/bin/nvim". But nvim still failed to start:

MainController: Neovim exited with code: 127
MainController: Neovim was disconnected

When I run nvim from a command line within VSCode, it gives /run/host/usr/bin/nvim: error while loading shared libraries: liblua5.1-luv.so.0: cannot open shared object file: No such file or directory (and then exits with code 127)

---

Related issues

https://github.com/vscode-neovim/vscode-neovim/issues/647 (someone struggling with setting the path in settings.json) https://github.com/vscode-neovim/vscode-neovim/issues/719 (finding workarounds to access files from within the flatpak) https://github.com/vscode-neovim/vscode-neovim/issues/685 (failing to find a workaround to access files from the flatpak)

VSCode installed via linux on a flatpak. Because of sandboxing issues, VSCode can't access my computer's installed neovim installation at /usr/bin/nvim

Definitely looks like avoiding one problem by creating many new ones, for both users and maintainers.

I tried LD_LIBRARY_PATH=/run/host/usr/lib/x86_64-linux-gnu/ /run/host/usr/bin/nvim but I got a segmentation fault. I'm on nixOS.

Mentioned here as well: https://github.com/vscode-neovim/vscode-neovim/issues/262#issuecomment-688568329

I was able to get this to work on nixos by installing via home-manager and including all of the extra languages (nodejs, python3, ruby).

Not sure which thing actually made it work.

You can get around the issue by installing Neovim on your local machine through Homebrew and use Flatseal to give VSCode access to /home/linuxbrew/.linuxbrew/bin/nvim or just the user home directory (i dont remember which one worked for me). Then in the extension settings set the executable path as: /home/linuxbrew/.linuxbrew/bin/nvim.

Same issue, it was maddening because for a while I did not realize this was a flatpak package . (I installed it through the distro Software app. It's mentionned it's a flatpak, but if you are just getting started on Linux and don't know what flatpak is and what are the implications... well, good luck)

I tried to use Flatseal to give VSCodium first acces to /usr/bin/nvim then I gave it access to binaries and executables but none of that seemed to work. It already had access to the filesystem, I did not change that.

I am on a Debian base distro so the workaround was simple : I gave up on flatpak entirely and just intalled the .deb for the projects's github release page and opened the download with de Gdebi installer and that was it.

You can get around the issue by installing Neovim on your local machine through Homebrew and use Flatseal to give VSCode access to /home/linuxbrew/.linuxbrew/bin/nvim or just the user home directory (i dont remember which one worked for me). Then in the extension settings set the executable path as: /home/linuxbrew/.linuxbrew/bin/nvim.

Using Pop OS 22.04 I used this a work around for the time being thanks!

Regarding some of the downsides, perhaps it's worth considering following the example of some other extensions that bundle binaries, e.g. clangd, vscode-go. Typically, the extension does not itself come with the binary but implements a command to (optionally) download/install it at runtime, and lets the user configure a path to either "bundled" or their own system-installed version. This also allows for updating the bundled binary even when the extension hasn't updated.

I think this would resolve all of the points here:

• Bigger download size. My nvim executable is 4.3M, and I don't know how big shared libraries will be.

• Not customizable. If somebody wants to run their own custom-compiled version of neovim, they also have to have a custom version of the extension.

• Delays neovim updates. If neovim has a security vulnerability and releases a new version upstream, then the extension also needs to release a new version.

• Might have problems being cross platform? Is it possible to include different executables for each target OS/architecture? I don't know enough about how extensions are published to answer this.

---

Separately, I wonder if the extension could do some kind of check for Neovim version... It seems a lot of bugs crop up which get fixed simply by users updating Neovim, so it would be nice if the extension could notify that either the current version is too old or that an update is available.

That said, many users probably don't want extensions reaching out to the internet without asking first, so perhaps an opt-in "automatically check for nvim updates" (or a prompt at first startup) would be nice. If the above "download neovim" command was implemented these could probably work together nicely.

Probably this could be a separate issue that would be less difficult to implement than the full bundled binary option, but just thought I'd mention it as a stopgap / alternative. It still is not a trivial amount of work however 😆

perhaps it's worth considering following the example of some other extensions that bundle binaries, e.g. clangd, vscode-go.

No, that's 100% out of scope and not going to happen.

Typically, the extension does not itself come with the binary but implements a command to (optionally) download/install it at runtime,

So then it becomes a package manager, which requires new options, features, and bugs.

I wonder if the extension could do some kind of check for Neovim version

It already does.

Status

• It is trivial to install Nvim, there is zero reason for a vscode plugin to do that for the user.
• Nvim node-client now provides getNvimFromEnv() to make it easy for node.js apps to find nvim on the system (example).

perhaps it's worth considering following the example of some other extensions that bundle binaries, e.g. clangd, vscode-go.

No, that's 100% out of scope and not going to happen.

Typically, the extension does not itself come with the binary but implements a command to (optionally) download/install it at runtime,

So then it becomes a package manager, which requires new options, features, and bugs.

Fair enough, especially since neovim would have different dependency requirements on different OSes, etc. This seems fair

I wonder if the extension could do some kind of check for Neovim version

It already does.

Ah, I thought it might but I guess the minimum version was only bumped to 0.9 pretty recently, and again to 0.9.2 with 0ccd64036d6caa7ea112065242b88e74f5422460

Do you think then it might still be useful to provide a hint to the user if there is a newer stable neovim version released than what they are running? The extension could query https://api.github.com/repos/neovim/neovim/releases or perhaps this kind of thing makes more sense in neovim/node-client as well?

Perhaps this suggestion is a little beyond the scope of this particular issue, so I can open a new one if it seems like something reasonable to have in this extension. Otherwise, I guess this issue can be closed since it seems like there is no further actionable work here.

Ah, I thought it might but I guess the minimum version was only bumped to 0.9 pretty recently, and again to 0.9.2 with 0ccd64036d6caa7ea112065242b88e74f5422460

Changing from 0.9.0 to 0.9.2 should have no significant impact. Most users have already updated to 0.9.2 after #1487

The main issue currently is that some users are using the dev version, which meets the version requirements but has incomplete functionality. @justinmk @theol0403

Do you think then it might still be useful to provide a hint to the user if there is a newer stable neovim version released than what they are running? The extension could query api.github.com/repos/neovim/neovim/releases or perhaps this kind of thing makes more sense in neovim/node-client as well?

Just reminding users when version requirements aren’t met should be enough.

Typically, the extension does not itself come with the binary but implements a command to (optionally) download/install it at runtime,

So then it becomes a package manager, which requires new options, features, and bugs.

Another good approach is to create a new extension specifically designed to assist users in setting up the nvim environment. It can be a package manager and we can add new options, features, and bugs in it. Also helps #262

The main issue currently is that some users are using the dev version, which meets the version requirements but has incomplete functionality

0.9.0-dev is less than 0.9.0 as defined by semver.

It can be a package manager

People can do that if they want, but it's a complete waste of time. If users can't use homebrew or other package managers, trying to fix that by providing a different package manager is a waste of time.

The main issue currently is that some users are using the dev version, which meets the version requirements but has incomplete functionality

0.9.0-dev is less than 0.9.0 as defined by semver.

However, the -dev version may also include the required features. Should users be forced to update to a stable version?

It can be a package manager

People can do that if they want, but it's a complete waste of time. If users can't use homebrew or other package managers, trying to fix that by providing a different package manager is a waste of time.

Agree, I have used vscode-neovim in codespace, and it is not troublesome to set up the environment, unless the user is really unwilling to do anything by himself.

However, the -dev version may also include the required features. Should users be forced to update to a stable version?

Yes. The cost of upgrading is small.

https://github.com/neovim/node-client now provides getNvimFromEnv() which tries to find nvim on the user's system and returns a list of all found Nvims, their filepaths, and any errors encountered (which can shown to the user). https://github.com/neovim/node-client/blob/06b4c185848a4c1e041d8cba267d8b9abac892f7/packages/neovim/src/utils/getNvimFromEnv.test.ts#L96

Closing as duplicate of https://github.com/vscode-neovim/vscode-neovim/issues/195

Can you summarize the impact of the new function on this issue? Is the plan that vscode-neovim would publish an update that uses the new function to select a correct neovim executable when installing, and better expose errors to the user?

If I'm understanding it right, I don't think that would have solved my original problem that made me open this issue (the executable wasn't accessible due to sandboxing issues). But it would solve some problems and make all of these problems easier to track down and fix.

Even with that function (assuming I understand its impacts), I think I would still be interested in bundling the neovim installation with the extension. I'm capable of managing a neovim install separately from VSCode, but it's just so much easier if software is self contained, instead of depending on other software being installed correctly.

Is the plan that vscode-neovim would publish an update that uses the new function to select a correct neovim executable when installing, and better expose errors to the user?

yes

If I'm understanding it right, I don't think that would have solved my original problem that made me open this issue

The current title of this issue ("include neovim in extension") is 100% out of scope and won't be implemented.