[mmahemoff]

It's disappointing to see from comments here that there's no true and performant Vim integration for VS Code.

It used to be the same thing with Eclipse and JetBrain's IDEs. Whatever Vim plugins existed were slow and falling into the uncanny valley, where they lacked support for many features or did things in slightly unexpected ways.

Torn between Vim and effectively Vimless IDEs, I chose to stick to the former and do what's possible to bring an IDE-like experience via plugins, though you still miss out on a lot in my experience, and any feature you want in Vim requires a lot more learning and configuring.

The promise of NeoVim was to provide true and complete Vim behavior in IDEs via its headless network protocol; but the indication here is it still hasn't happened.

[ubercow13]

It's here https://github.com/asvetliakov/vscode-neovim

[meestaahjoshee]

IdeaVim in intellij isn't too bad, it even reads your .vimrc (just source ~/.vimrc in a ~/.ideavimrc file) and while it doesnt have much in terms of vim plugin support, the basic vim vocabulary is there which has been good enough for me.

i had to switch to go/java for work and this has worked better for me than simply writing everything in vim - although vim-go is great, i enjoy being able to run and debug my tests and code in intellij.

[yodsanklai]

> It's disappointing to see from comments here that there's no true and performant Vim integration for VS Code.

I've been using vscodevim daily for almost 2 years, and (for me) it's totally usable. IMHO, much better experience than trying to turn Vim into an IDE.

[jamesgeck0]

Yep. It's not 100% perfect, but it's good enough.

Of course it's also be great if I could figure out why my language server plugins for Vim cause the entire editor to freeze up for a few seconds periodically despite running asynchronously, or why my intellisense menu plugin flickers like crazy every time I pull it up. But the ways in which VsCodeVim don't work for me are more conducive to getting things done than the ways Vim doesn't work for me.

[nonbirithm]

As a completely biased user/person who is insane enough to adopt an editor as a lifestyle, I've been using a vim emulation layer for Emacs (Evil) and I've in a sense gotten used to it.

That comes after dozens of hours twiddling around with configuration files that let you set leader-based keybindings and change pretty much every aspect of how the vim emulation behaves. And after using it for a while I've found it behaves pretty much exactly like vim, which in itself is a godsend in a plethora of vim emulation plugins that don't get everything quite right. Somehow it just works how you'd expect. If lsp-mode becomes stable enough we might live to see "IDE"-like features in Emacs being workable.

I wouldn't recommend this approach for everyone, though. Because most of Emacs was not designed to use vim emulation you often have to switch between plain Emacs and the vim layer really often, or even worse write entire keymaps for unsupported features. When you have to do this depends on the functionality you want to use, and this is variable enough that it's not possible to immediately get used to - you have to learn how everything works first and adapt your muscle memory/config to it.

Evil is also baked into Emacs, so you'd have to use Emacs with its 44 years of cruft and get used to its unique methodology to take advantage of it. People may either become disinterested in this or completely entranced by it (see: the author). Either way, you'd be spending time learning a lot of new editing paradigms instead of doing actual work.

Also Emacs is slow when opening and searching big files, and this stems from a fundamental decision about how Emacs stores open files in memory. In those cases I have no choice but to open a minimal vim to edit them.

In addressing the slowness problem the xi editor[1] is trying to move in the direction of never blocking the user's input and separating frontend/backend. However, last time I checked the JSON-RPC they were using was not performant enough for their needs. There was also a huge debate on how to do collaborative editing, and the problem they eventually stumbled upon was that in some cases you'd have no choice but to essentially do the same thing as git merge does to resolve editing conflicts. Also because the protocol is so generic people ended up creating dozens of frontends in several different languages that support different feature sets instead of combining all their effort into making an even better standardized client.

Text editors are at the same time universal and full of tough issues to solve. It is indeed a shame that the programs that are most capable of running programs lack good text editors, and vice versa. One time I got fed up with having to constantly use the mouse when using IntelliJ so I wrote an LSP server embedded as an extension so it could be controlled from emacs. Unfortunately I didn't have the time to constantly keep up with the internal APIs that broke every few weeks and fix all the edge cases.

[1] https://github.com/xi-editor/xi-editor