The Emacs experience on Windows could be faster, but having switched from Neovim to Emacs on macOS I do not want to go back to Neovim now (and I was running the Neovim 0.5/dev branch with LSP and treesitter integration for some time). Your time might be better spent on improving Emacs performance on Windows if you can. I haven’t used Emacs on Windows for a little while, but I wonder if running it via WSL2 with the new Linux GUI integration is better than the native Windows experience?
I spent months trying to mould Neovim into an IDE-style environment I could love (people seem split about whether Neovim should be an IDE or not, but it feels like it’s evolving in that direction).
I tried Doom Emacs because of the buzz around it, fell in love straight away, and built my own Emacs config from scratch to get a better understanding of Emacs (I like Doom, but I found it hard as a new Emacs user to grok the separation between Emacs/Doom/external packages; the appeal of Emacs for me is to shape the tool to your needs and to understand what the packages you’re using do and how to tweak and customise things).
Neovim is improving but it still falls short of Emacs by far in my opinion. Some things to be aware of from my experience of both environments:
Neovim UI is inconsistent. With Emacs I can have every package use Ivy for item filtering and selection, for example, where as Neovim plugins often end up inventing their own UI because there’s no real UI standard in the Neovim space. Even Neovim packages that build good UIs (telescope) feel buggy and laggy to me compared to Emacs equivalents. (I had a persistent issue with telescope where trying to close the popover would take multiple attempts or not work at all).
Package quality is _so_ much better for Emacs. I tried a bunch of different Vim/Neovim git plugins and none of them are close to magit. When I ask Neovim users what they recommend for git integration, they suggest plugins that don’t hold a candle to magit (fugitive), external CLI tools that aren’t integrated with Neovim (lazygit), or say something like, “just use git on the CLI via tmux or iTerm tabs! Vim isn’t supposed to be an IDE on its own - you compose Linux tools in isolation into an IDE”. That’s fine if you embrace that mindset, but I find it unsatisfying now that I’ve used magit for some time. It’s a similar story for pretty much every IDE problem space (projectile and Cider are so much better than their Vim equivalents, for example).
Documentation quality is generally much better with Emacs, particularly when writing plugins. (Lua APIs are documented for Neovim but not to the extent that Elisp functions are.)
Emacs Lisp is also so much nicer to work with than Vimscript and Lua. The ability to run expressions in the environment without reloading whole files or restarting is a superpower, especially when making plugins.
I don’t mean to crash the Neovim 0.5 launch party here – by all means try it! Just be prepared to trade some of your Windows speed-related frustrations for general UX/UI/polish pain points instead. :-)
But neovim is only getting started. In a few years, the benefits of elisp over lua will probably be nil, and luajit is faster. I expect a lot of these points you make (which are valid) to become less and less relevant. First examples are already there : treesitter is as clean as can be, and telescope looks extremely nice. I'm waiting to see what people come up with for git, now that they don't have to learn vimscript or use slow python plugins.
That sounds a lot like the old annual joke about Bluetooth: “sure, we know it’s kind of rough around the edges today, but you just wait – it will be amazing next year!”
I agree with you that Emacs and Neovim are at different levels of maturity. And I agree that Neovim could eventually gain better docs, more mature and stable packages, more consistent UI conventions, a better Lua dev experience, less experimental and more actively developed GUIs for those who need something more flexible or accessible than a terminal-drawn UI, better filter-pickers, better documentation for LSP integrations, better git integration, better GitHub/GitLab/forge integration, better plugin dependency handling, a better governance story, a healthier bus factor and contribution story, and more thought about the impact of a fork on the Vim community as a whole.
What I disagree with is the idea that “Neovim will be just as good or better than Emacs in a few years and all your current qualms will mean nothing then” is a compelling reason to use Neovim over Emacs today. My list above is a lot of work, and that’s just to reach parity with Emacs, which will also be maturing and improving in that time. To exceed Emacs for me Neovim would need to do all of that and more, or all of that but better and faster.
I don’t doubt that Neovim will get better really fast because the velocity so far is strong. But right now Neovim feels like a scrappy collection of hacks and experiments from a community of enthusiastic prospectors and beta testers who collectively seem to have no common opinion about what they’re even hoping to build (some still feel that Neovim should not become an IDE or that as much functionality as possible should be shelled out to CLI dependencies).
It’s exciting to be part of a bleeding edge editor community if you’re happy to write or contribute to plugins and try out and configure a bunch of existing ones every few months. It’s less great if you want stable IDE-like features now that feel like they were designed with taste and consistency and have been maintained with love for years.
I don’t really have a horse in the race except that I spent a _lot_ of time configuring and building things for Neovim while using it as a daily driver that I now wish had been spent on Emacs instead. I’m also excited that we have such strong communities of Neovim and Emacs hackers today that both are fun to hack on, get work done with, and continue to argue about with strangers on the internet.
I spent months trying to mould Neovim into an IDE-style environment I could love (people seem split about whether Neovim should be an IDE or not, but it feels like it’s evolving in that direction).
I tried Doom Emacs because of the buzz around it, fell in love straight away, and built my own Emacs config from scratch to get a better understanding of Emacs (I like Doom, but I found it hard as a new Emacs user to grok the separation between Emacs/Doom/external packages; the appeal of Emacs for me is to shape the tool to your needs and to understand what the packages you’re using do and how to tweak and customise things).
Neovim is improving but it still falls short of Emacs by far in my opinion. Some things to be aware of from my experience of both environments:
Neovim UI is inconsistent. With Emacs I can have every package use Ivy for item filtering and selection, for example, where as Neovim plugins often end up inventing their own UI because there’s no real UI standard in the Neovim space. Even Neovim packages that build good UIs (telescope) feel buggy and laggy to me compared to Emacs equivalents. (I had a persistent issue with telescope where trying to close the popover would take multiple attempts or not work at all).
Package quality is _so_ much better for Emacs. I tried a bunch of different Vim/Neovim git plugins and none of them are close to magit. When I ask Neovim users what they recommend for git integration, they suggest plugins that don’t hold a candle to magit (fugitive), external CLI tools that aren’t integrated with Neovim (lazygit), or say something like, “just use git on the CLI via tmux or iTerm tabs! Vim isn’t supposed to be an IDE on its own - you compose Linux tools in isolation into an IDE”. That’s fine if you embrace that mindset, but I find it unsatisfying now that I’ve used magit for some time. It’s a similar story for pretty much every IDE problem space (projectile and Cider are so much better than their Vim equivalents, for example).
Documentation quality is generally much better with Emacs, particularly when writing plugins. (Lua APIs are documented for Neovim but not to the extent that Elisp functions are.)
Emacs Lisp is also so much nicer to work with than Vimscript and Lua. The ability to run expressions in the environment without reloading whole files or restarting is a superpower, especially when making plugins.
I don’t mean to crash the Neovim 0.5 launch party here – by all means try it! Just be prepared to trade some of your Windows speed-related frustrations for general UX/UI/polish pain points instead. :-)