Show HN: Build your own Vim emulation for VS Code
johtela.github.io
johtela.github.io
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.
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...
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.
Sounds kind of weird now that I’ve put it in writing. It works for me but YMMV.
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.
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'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.
https://marketplace.visualstudio.com/items?itemName=auiworks...
See also: https://stackoverflow.com/questions/1218390/what-is-your-mos... aka "Your problem with Vim is that you don't grok vi."
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.
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?
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...
I'll check the LitScript also. Yours sounds like quite a workable workflow.
https://marketplace.visualstudio.com/items?itemName=gregoire...
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).
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.
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.
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.
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.
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.
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.
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.
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.