> [!quote] TL;DR > Text editors should use a real, fully-functional embedded Vim process rather than reinventing vim functionality with an emulator. Doing so means happier users, less dev work for everyone involved and _WAY less_ maintenance burden for maintainers. > > Despite this, most attempts to bring Vim to other text editors use emulation. For those of us that took the time to learn Vim (or `vi`, `nvim`) being able to use that muscle memory in a new editor is _table stakes_. It's so fundamental to the experience that people still use Neovim, MacVim and other forms of The Real Thing™ because they know it will work, and will support all their quirky customizations. What boggles my mind, and the reason for this blogrant, is that _you don't have to choose_! If you create a text editor, you can both save yourself effort _and_ provide a fully featured Vim experience by embedding vim rather than emulating it. # Emulation Vim emulation is when a text editor writes (a lot of) custom code to support Vim's features. Most notably, modal editing. In modal editing you choose which "mode" you are in and keys do different things depending on which mode. The two main modes are movement and editing modes [^1]. - Movement: The keys `h/j/k/l` will move the cursor around the page rather than output those literal characters. Imagine typing `j` and your cursor moves down, rather than inserting "j" on the page. - Editing: The keys do exactly what you expect, they insert letters on the page. If you've ever used a text editor or word processor you're familiar with this. Many, many text editors over the years would emulate Vim in order to support the vocal minority of users that can never go back. Off the top of my head: - The entire JetBrains suite of tools (IntelliJ, WebStorm, ...) - Sublime - Zed - VSCode - Atom (defunct) - Emacs (!) _Every single one of these tools_ supported Vim **emulation** to varying degrees, and with the exception of Zed I have first-hand experience using Vim mode in all of them. It was a very dissatisfying experience. The problem with emulation is that it misses corner cases and sometimes even primary use cases. Example: As a Vim user, I want to be able to use _my existing_ Vim keybindings in the Vim emulator. However, this is often not possible or requires rewriting all your Vim rules to some new configuration langauge (probably JSON). Why? Am I advocating every Vim emulator ship a VimL interpreter? What about Neovim users, should Vim emulators ALSO ship a Lua interpreter? Well, I would say yes, but embedding is a better option. I believe software should meet users where they are, rather than requiring users to modify their behavior to suit the software. Building out 100% feature compatibility with Vim would be a monumental undertaking, which is why embedding is a better option. Embedding Vim, rather than emulating it, gives the user what they want while also decreasing the eng effort required by the editor team. It will It's a win-win. It will also drastically decrease user requests, which take time and attention to triage. Example: Take a look at the open issue count for [VSCodeVim](https://github.com/VSCodeVim/Vim) (emulated Vim) and [vscode-neovim](https://github.com/vscode-neovim/vscode-neovim) (embedded Vim): ![[CleanShot 2025-05-21 at 10.42.10 1.png]] ![[CleanShot 2025-05-21 at 10.42.24 1.png]] Consider that for a moment. The Vim emulator has twice as many stars[^4] but 30x more issues! I will also note that both projects are active, with releases in the last 2 weeks. So the issue count in the vim emulator cannot be explained by lack of maintenance. # Tradeoffs It would be unfair to say that embedding VIM is 100% better than emulating in every case. There are definite trade-offs here. At the top of my mind would be that by embedding Neovim you're creating a small distributed system. You have VSCode and you have Neovim, and they have to communicate. If anything happens to the Neovim process your editing experience blows up[^2]. Believe it or not, this happens _all the time_, and I _still_ advocate for embedding Neovim. Despite the editor sometimes freezing you can very quickly restart the extension. It's instant, orders of magnitude faster than starting up VSCode itself. ![[CleanShot 2025-05-21 at 10.17.07.png]] However, what you get by accepting the tradeoff is real vim. You can to write all the obscene keyboard mappings you want. You get the full customizability of Vim with the plugin ecosystem of VSCode. Furthermore, most VSCode users are _already_ running a distributed system because they are making use of one or more LSPs for their programming language. So, in other words, to fully avoid this issue you would have to give up VSCode itself. Unsurprisingly I think the tradeoff is worth it—By embedding Vim you get the best of both worlds. You get an editor that works well without customization and has a fast extension ecosystem, and you also get the hyper customizability and modal editing of Vim. ## Developer Tradeoffs That's just the user facing side. On the developer side the benefit of embedding vs emulating is more stark: Save yourself 100s of hours of dev time. Emulating means _rewriting_ the functionality of Vim within your system. Vim is non-trivial software that has accumulated features for decades. If you want to satisfy Vim users you also want to support esoteric features those users depend on. # Future Perhaps this will be a non-issue in a decade (or sooner). Two points come to mind: - If AI gets good enough at writing software we simply won't need to type anymore. - Perhaps the youth simply won't learn Vim. The first point would get a bit speculative so I'll just gloss over it by saying that AI is _not yet_ good enough to remove the human programmer from product building—I've tried. I _want_ the AI to be that good. It makes development of prototypes way, way faster, but it's not yet there when it comes to building production software end to end. I have really tried to make my own skills irrelevant as I build my own side projects, and I have not yet been able to displace myself with AI[^3]. On the second point, I have no idea what kids these days are into. My oldest can is barely at the speaking stage, so he's still a ways away from giving me insight into his generation. What are kids in their teens and early 20s learning? Does anyone still learn Vim? I have no idea. It's entirely possible that given enough time too few people will care for text editors to worry about either embedding or emulating Vim. ## What do we want? Better BCIs I think it's worth taking a figurative step back and talking about what we are actually going for here, which is _faster/better brain-computer interfaces_. The whole point of VIM is that if you write a lot of text or edit a lot of text, you generally want to be faster at doing that. One way to get faster at this type of task is to offload the core mechanics of it to muscle memory. Muscle memory is Multitasking That Works™. Learning VIM is akin to learning to play an instrument. It is not intuitive out of the box, but once you learn it, you don't have to think about it. You can communicate with the computer much faster, because your mind is free to focus on the content of what you're writing rather than the mundane activity of slapping fingers against keys in rapid succession. So one even more speculative way that we might replace VIM and everything like it is to have an even better way of communicating with the computer. Perhaps we'll find a way that is more efficient than typing on a keyboard, and ideally more accessible to a large number of people. Here's hoping. 🍻⌨️ [^1]: In the Vim world these are called "normal" mode and "insert" mode respectively, but normal mode is just so vague that it will only have meaning to those of us that have already been indoctrinated (hi friends👋) [^2]: Namely, your editor stops responding to keystrokes. This happens _all the time_, unfortunately. But you know what? I still choose this over emulation. The Neovim server can be restarted almost instantly, so in practice it's not nearly as onerous as it sounds. [^3]: Not to future readers, i'm writing this on 2025-05-21. So if you're reading this from the AGI future, that's the historical context. [^4]: The star count is also unfortunate. Users of the vim emulator would be better off with vscode-neovim, but it's harder to find. VSCode docs inexplicably link to the worse option, which I would guess accounts for it having more attention on Github.