Add neovim integration

[jspieker]

• Click thumbs-up 👍 on this issue if you want it!
• Click confused 😕 on this issue if not having it makes VSCodeVim unusable.

The VSCodeVim team prioritizes issues based on reaction count.

---

FEATURE REQUEST:

I'd love to see a Neovim integration in VSCode in order to use my native and more stable vim commands and only having to set up a single .vimrc file. Some other editors are already supported, and the plugin UI architecture explains how to implement it into a GUI. Is there any chance of this happening?

[Chillee]

I've thought about this a decent amount, and the issue is tricky. Conceptually, using neovim as the backend is appealing to me as a programmer. It seems like the "right" way to do it. However, there's a couple reasons why neovim integration didn't happen/ roadblocks to doing it in the future.

1. When this plugin first started being developed, Neovim RPC support was pretty crappy. It definitely wasn't ready for use.

2. Nobody else seems to have done it well. I'm only aware of 2 other attempts to integrate neovim into actual editors. https://github.com/carlosdcastillo/vim-mode and https://github.com/lunixbochs/actualvim The author seems to have given up on the first one, but the second one is actually pretty good. However, there still are a couple of fundamental issues with the second one. I've had issues with hanging, snippets, multicursor, gj/gk, and autocomplete don't really work, highlights don't really work, and in general, a lot of the things that involve UI syncing between neovim and sublime that aren't just text based don't really seem to work.

In addition, ActualVim has the advantage of having an already existing python interface for interacting with neovim: https://github.com/neovim/python-client

Don't get me wrong, ActualVim is great, and the work:results ratio is far better than this plugin's. If I was starting today, I would probably use neovim rather than try to replicate the work we've done.

However, fundamentally, it seems difficult to integrate a lot of the vscode specific stuff. As the primary vim plugin for vscode (which means that this plugin's quality is a large adoption blocker for vscode), it's preferable to choose the route that enables more features. Even if the issues I mentioned above with ActualVim are surmountable, it's risky to put all that effort in only to realize that crucial feature is impossible.

3. We don't want to redo work we've already done. This plugin has had a lot of work put into it to get it to its current state, and it seems to work very well for me. Pretty much all the features that I used in Vim are implemented in this, and even all of the plugins I used (ie: surround)! I'd rather spend the effort to fix the bugs in this extension rather than rewrite it from scratch. It's kinda like RIIR (rewrite it in rust). If you have specific issues with this plugin, we could fix those bugs :)

4. There's not actually as many benefits as you'd think to having a .vimrc and supporting vim plugins. Most vim settings still aren't supported by us, and the majority of vim plugins wouldn't be supported anyways (ie: fugitive, easymotion, etc.)

That being said, trying to add neovim integration is still a long term goal of mine. There are a couple places neovim integration could add substantial amounts of new functionality without interfering with what's already implemented. Namely, Ex-commands.

Here's some links to discussions from other vim plugin writers about neovim integration:

VsVim/VsVim#1899
https://youtrack.jetbrains.com/issue/VIM-858

[johnfn]

We even have our own old discussion about NeoVim: #18

I think the "rewrite it in rust" comparison is incredibly accurate here.

[jspieker]

Thank you for the detailed reply! As much as I'd like to see it, your points make sense for now.

What do you think about pointing to an existing .vimrc inside of VSCodeVim and "translate" the vim native commands to VSCodeVim settings, to make it easier for new users to get started with their hotkeys, key delay, relative line numbers etc? I'm thinking about a solution similar to the one ideaVim uses.

[Chillee]

@fasoh It's fairly difficult to do that, although it certainly is a long term goal. Parsing the .vimrc isn't trivial, and for the amount of work needed, we won't be getting that much out of it. A lot of vim commands don't have an equivalent in vscode, scrolloff and virtualedit for example. However, it certainly does make the transition easier, and it's definitely something I want to attempt over the summer.

[Chillee]

I've gotten a proof of concept working here! #1725

It should support all text-editing Ex commands.

[jspieker]

That looks really promising, count me excited!

[Chillee]

I'm gonna close this issue in favor of #1735.

[lunixbochs]

@Chillee I've pulled your feedback into an issue on actualvim. All of these are addressable and will be addressed: https://github.com/lunixbochs/ActualVim/issues/106