Show HN: Build your own Vim emulation for VS Code
johtela.github.ioThis is an interesting approach. I find the popular vim emulation extension (vscodevim) is a bit buggy and has lots of "uncanny valley" gaps.
At work I use vscodevim, and at home I use vim with TypeScript plugins. Both approaches have lots of annoyances. Maybe a weekend dedicated to ModalEdit could give me the experience I'm really after. I'm also excited for Oni Vim 2, which is a commercial product who's promise is to provide the best of both vim and VS Code.
Let us not disparage VSCodeVim in the least. #1: .vimrc support. Simply huge. Not everything is there, but a lot is.
Also, they are responsive. The big outstanding thing for me is Code's behavior with respect to opening a new file/buffer. Tabs are owned by splits whereas it's the other way around in Vim, and that's fine, but the Vim default of replacing the active file/buffer must be!
I figured out a workaround [0] just this week with a little help, but more importantly, after suggesting that this feature make it into the extension, I received a prompt reply [1]. These people are doing great work that really matters for me professionally.
Good luck implementing the 8,000,000 Vim features that you use and don't even think about by starting with nothing but a context for mode-switching.
[0] https://stackoverflow.com/questions/60216168/vscode-open-fil...
I don't mean to disparage it. Apologies if my post came off that way. I certainly appreciate it and understand emulating vim is not an easy task.
Yeah, I was thinking I may have been a bit aggro there. It's just a coincidence that I only recently embraced IDE life (finally!), and it's in no small part because of this extension. Cheers.
No, I appreciate the call out. My intention wasn't to be negative, but I really was in retrospect. I will be more mindful in the future.
One of the most annoying thing with this extension is that it maintain a different revert history that is conflicting with the normal one. Sometimes you just have to close a file without saving it because undo/redo is broken.
And it's extremely slow on medium to large files and it gets slower and slower until you restart vscode.
I have a love hate relationship with this extension. It's terrible but vscode without it feels worse to me. Sometimes I wish I didn't met vi in my life.
I’ve kind of learned how to juggle the two disconnected undo buffers in my mind. If I want to just go “back in time”, repeating even my previous undo/redos, I use Ctrl-Z. To undo a quick mistake I use Vim’s undo. I guess I treat them like short-term and long-term “undo” actions.
Sounds kind of weird now that I’ve put it in writing. It works for me but YMMV.
Heh, that’s how I feel after reading this article. I don’t use vim a lot, haven’t gotten used to it. It must be so frustrating always having to chase that “vim experience” in every editor, but never quite getting it.
Have you tried the neovim integration setting? I find that almost everything works as I would expect it to nowadays.
I am using it and I am considering disabling it on a daily basis. Not only is it slow as mentioned elsewhere, it interacts poorly with other VSCode features, like automatic bracket matching, intellisense etc. I find that when recording macros, I have to be very careful to consider what the vim part might think just happened and try and work around it.
But every time I disable it, I immediately miss normal mode. So yeah, as happy as I am with VSCode (which is a lot), the situation is suboptimal.
As an advanced (neo)vim user, I respectfully disagree. Vim integration in VS Code is sluggish and buggy (see folds and macros, for example).
That only uses neovim for ex mode. Full integration of neovim requires digging into less widely used extensions such as https://github.com/asvetliakov/vscode-neovim
I found vscode macros particularly painful. Slow & where vim optimizes things. Typing abc^H^Hsdf will seamlessly play out as asdf, but with vscodevim I have to watch the macro repeat my mistake each time
I have used this extension a bit and it works great as far as I can tell. Whereas with the older popular VS Code vim extension, I would get broken behaviour within minutes of use. And I am not a particularly proficient vim user, this would have just been navigating, using visual mode a bit, correcting some stuff.
this one or something else? https://marketplace.visualstudio.com/items?itemName=asvetlia...
I've been waiting for someone to make that work before diving into vscode and if it's solid looks like I have my weekend project.
The vscode-vim extension has an option to use neovim for ex mode commands
Your take on vscodevim is a sort of "glass half empty" kind of argument. To be fair, vscodevim is fantastic and it gets a lot more thing right than it gets wrong.
I also had problems, mostly around multiple cursors, and found the less popular amvim to be much better. I have not run into any problems with it so far, hopefully this will work for you too
https://marketplace.visualstudio.com/items?itemName=auiworks...
Vim's power doesn't come from using single-letter commands to do things but, rather, in the language-like (action, verb, noun) expressions the whole ecosystem enables: "daw" to delete a word, "cit" to replace the "inner" part of a tag and start typing, numbered prefixes to execute an action that number of times, etc.
See also: https://stackoverflow.com/questions/1218390/what-is-your-mos... aka "Your problem with Vim is that you don't grok vi."
OP here. I completely agree with that. The goal of ModalEdit is not to emulate those verb-noun commands. VS Code's commands operate on selections, so it is very cumbersome to turn them to work in Vim way. Instead, you should try to mimick something like [Kakoune][1] which is another modal editor that uses the selection as command target.
I'm sure ModalEdit doesn't tempt any hardcore Vim users to use VS Code. But there are a lot of VS Code user's who have used Vim and like idea of modal editing. Having an extension that you can configure from ground up is the value proposition I was aiming for; not to make a poor man's Vim clone.
Well, this certainly looks interesting. You mean I could use ModalEdit as a basis to bringing Kakoune like selection behaviour to VS Code as long as I'm willing to configure it? I have played with Kak, but Code's extensions are easier to use and more powerful still. I so very much would like to get the best of both.
Have you used Kakoune yourself? Is there something that's currently not feasible with VS Code using ModalEdit? I'm still going through ModalEdit docs to get an idea of what's possible.
Also, Literate Configuration is a good idea. I don't suppose there's a Jupyter notebook like editor available where markdown and code parts can be seen alongside in fully rendered form?
I have to admit that I haven't used Kakoune myself. I just like its approach of taking the good parts of Vim and adapting them to more "mainstream" style of editing.
Because Kakoune's editing operations are much closer to VS Code than Vim's, I think you can copy its functionality quite extensively with ModalEdit. The only limitation is that VS Code itself needs to have the commands to support these operations. The configuration involves just binding key sequences to the commands. However, VS Code marketplace has so many command extensions, so I bet you can find substitutes for most Kakoune features there.
Regarding the literate configuration, there is no Jupyter-style online editor for it, afaik. I use (of course) VS Code to edit my `settings.json` file. In the background I run [LiTScript][1] in watch mode to generate the documentation on the fly. I also use the [Live Server][2] extension to automatically reload the generated documentation when it has been changed. With this setup, saving the `settings.json` file causes VS Code to reload the configuration, LiTScript to generate the updated documentation, and Live Server to reload it automatically. So, it is almost like Jupyter in the sense that you see your changes in effect immediately.
[1]: https://johtela.github.io/litscript/ [2]: https://marketplace.visualstudio.com/items?itemName=ritwickd...
Thank you. I'll be sure to check ModalEdit. Since VS Code is so easy to extend I guess I'll just have to find what things to copy over from Kak. Since Kak can be used as a server also (https://github.com/mawww/kakoune/wiki/JSON-RPC) I can send stuff over to it for more extensive editing.
I'll check the LitScript also. Yours sounds like quite a workable workflow.
“Dance” is a VSCode extension that provides Kakoune inspired key bindings. I have tried it but have never seriously used it. Will give ModalEdit a try.
https://marketplace.visualstudio.com/items?itemName=gregoire...
Thanks. There's also https://github.com/reykjalin/kakoune-mode which sends input from VS Code to Kakoune and shows its output back within Code. I haven't tested it yet, though.
And then you start recording those expressions into macros just by pressing q. Or just repeat the last one with a period. Vim is so great in so many ways, I always have to use a Vim emulation layer when using Visual Studio.
One of the best resources that I have used (in the distant past) is vim golf[1]. It's a super fun way to level up your vim skills.
The issue I always had with it is that you can’t see the really good answers (unless that’s changed). I wanted to push an “I give up” button so I could access answers that would help me learn.
That was always the best part of ProjectEuler was seeing everyone else’s answers after solving the problem.
I feel like this is missing the point of Vim a little bit. It's not about using hjkl instead of arrow keys. It's about progressively learning a vast and useful language specifically made for editing text efficiently. And then realizing you can use every single part of that language in a macro. And then realizing you can use that same language to orchestrate those macros.
Why use VSCode at all then? I've found coc.nvim and language servers to be every bit as good as VSCode in terms of code completion and definitions.
I'm mostly writing Go, C, Javascript, and HTML/CSS. But, so far it's been working great. And, I'm a fairly recent convert to vim (neovim).
For those that are unaware, it’s literally the same system underneath. Vscode talks to language servers to do all the work and they’ve architected the system in such a way that others can talk to them too. Coc.vim provides the plumbing to do that from vim. It’s a great project. Took me a while to get things configured properly but it’s been great for doing all my typescript work.
Is anyone aware of an 'opinionated' neovim distribution?
Something like spacemacs or Emacs Live, that takes care of all the configuration work to give a solid basis out of the box.
I've been dragging my feet on switching everything to nvim because I don't have 'awhile to get things configured properly' these days.
At least with coc.vim it's literally just a case of picking a vim package manager and using that to install it. Almost no configuration required, apart from `CocInstall`-ing whatever language servers you want.
The only thing which makes me not switch from VSCode to Vim is the debugger (specifically Node.js). I haven't found anything in Vim to make debugging pleasent. I hope there will be an easy to use Debug Adapter Protocol frontend impementation for Vim.
I switched because I found that it was a more coherent experience overall. With vim I was always editing my vimrc file and struggling to make plugins play well together.
That might be specific to my requirements/preferences or it might just be the fact that I am not skilled enough but in spite of issues (that I outlined in another comment https://news.ycombinator.com/item?id=22385285), I still find it more pleasant.
I use Vim but one thing that VSCode has that Vim does not is the idea of remote containers.
With VSCode, it's pretty nice and easy to get perfect auto-complete, definitions, etc. from code running in a container.
With Vim, AFAIK there's not anything near as seamless to do the same thing. In fact, I've found nothing that even tries to do it.
Yeah, ever since LSP became a thing (thank you TypeScript!), Vim got better with LSP clients. Soon, it will even be built into NeoVim!
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.
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.
> 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.
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.
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.
One of the biggest issues with Vim emulation in VSCode is that VSCode has no concept of text objects. Because of this, things like "change inner word" or "paste" will always have to delete text character by character and re-type (in the case of the latter). It's sort of like watching a ghost type. I'm still very impressed with how well it's all working. Atom has AMAZING Vim emulation, but its text rendering engine is different. It'll be interesting to see what the Oni folks come up with.
For my specific use case the integration is awesome. I can edit text super fast with all vim keybindings. I also appreciate having the easy motion plug-in by default, which I also love. I understand that people who know the depths of vim may lack features they are used to. But for the majority of us it really improves our coding experience, and at the same time we don't spend time struggling to add ide features into vim, because vscode is already a great ide. So when I start using a new file type it just works or there is a plug-in for it. Same with debugger, compiling, and so on.
I’ve really wanted to write a Kakoune style layer for VS Code or even a Kakoune style editor that works natively on Windows.
That would be really interesting to me. I have been eyeing Kakoune for a while and love the idea but I'm too invested into VS Code to completely switch editors.
Just use Evil and have the best of both worlds.
Why not just use Doom Emacs?
nice article