Neovim I have a borderline inappropriate amount of tweaks ’n other nonsense that goes in on my vim configuration, but it’s quite nice. I use sandwich.vim rather than vim-surround, mostly due to its support for the function text object (and a few other interesting-yet-niche features).

It’s got a fairly large focus on language servers, performance, and never slowing down. Not quite true to the promise, but it’s quite performant for the amount of stuff it throws around. Next major improvements will be migrating the configuration to lua once a lua vimrc is fully supported, and switching the language server to the neovim builtin one once that gets a few remaining features

  1. coc’s proper selling point is that it’s an almost complete port of vscode’s language server implementation into neovim. This is important because vscode’s language server implementation is the defacto. It breaks the LSP spec in several ways and implements features not in the spec; it is, in essence, the IE6 of language servers, and if you want language servers to “just work” without them having to carefully test on both neovim and VSCode, you will get the best experience by far with coc.nvim. Luckily this is slowly changing, and so by the time the neovim native LSP is “fully baked” it should be nearly drop in. In that regard, yes, the memory usage of spawning N*M node processes (N = per language server activated, M = per buffer open) is excessive, but the tradeoff is compatibility in an ecosystem that has not yet achieved it.
  2. neovim is excellent. I much prefer it to vim for philosophical, social, and technical reasons. Probably the biggest difference is all of the things that are enabeled by a welcoming community and the quality of life that comes from seriously addressing technical debt. The addition of the lua engine as well as the fully featured remote-embedding protocols is the biggest user-visible factor towards this because it allows plugins to have very high speed performance without needing to do ugly C FFI hacks through python/node/etc (thanks to the magic of luaJIT). Native lua support for the vimrc also allows you to do wild things, like compile fennel (a lisp) with AoT optimizations to ultra efficient lua bytecode and load that up as your vimrc.

Neovim’s addressing of technical debt also makes it very possible for their async job API to be much better than vim’s (which came after and was purposely made non-compatible with neovims for political posturing reasons). But, the bigger underlying impact is things like tree-sitter; tree-sitter allows neovim to get a full semantic highlighting (seriously; it can even correctly highlight C++ template code and Agda), symbol replace, and basic refactoring without ever needing a language server. Tree sitter also allows for the creation of native vim text-objects that are semantic in nature (eg a function text object that actually works and doesn’t assume c(style,fns){} Between that and the built in LSP, neovim is in a really strong position to be highly performant, highly intelligent, and able to be embedded inside any other text-editing interface (like web browsers, and vscode).

It’s a hell of a lot more than vim with a sane vimrc, and I wouldn’t be surprised if it eventually ends up obliterating the BDFL model of vim proper in time. Indeed, some of the capabilities that neovim currently has, and certainly ones that it will eventually have, will never be able to be fully replicated in vim.