1) nvim's built in lsp client is entirely in lua and afaik none of it is related to the nvim core. It is not inconceivable to just move it to a plugin but pretty much everyone will have to depend on it. I think for something as powerful as lsp, it might as well be bundled.
2) the built in lsp client in lua is EXTREMELY customizable and lightweight. In fact, a lot of useful features are enhanced or extended with plugins. Putting the onus on plugin writers to rewrite essentially the same functionality is not ideal.
3) The people that built the lsp client are extremely passionate about it and have contributed to neovim. tjdevries has some youtube clips and twitch stream clips where he talks about why this is a good idea. One thing that was mentioned during the stream today was that luajit and using libuv / LUV makes you feel like why not write an LSP client in nvim lua.
I personally think since it is so lightweight and since it is all in lua, it's awesome to have. And the next big thing can also be added to nvim base in lua without too much "cruft".
This goes back to my biggest complaint with the vim ecosystem (and emacs has the same problem): no dependency management. Almost every plugin has to be self contained, because if you depend on another plugin, then you need to rely on you users to manually install that plugin.
However one thing I wish emacs packages had was the ability to version dependencies. Right now you can get a broken plug-in because the upstream package introduced breaking changes.
• LSP means Language Server Protocol [0]
• ALE means Asynchronous Lint Engine [1]
It would be interesting if ALE could integrate with nvim's LSP implementation though, although I'm not sure how that would work.
Also I'm just too old to learn the whole Lua API.. That's not something I hold against nvim, but it's a reflection on my laziness? I just want a good vim based experience and nvim did that for me.
Btw, I paid for Onivim2. Was surprised by its snapiness but it's pretty useless as a working editor if you want equivalent features to nvim
I'd mirror your comments, and especially emphasize the speed aspect. (I think your ordering of comparisons matches the ranking of differences).
how would you compare to nvim? i tried vsc with a vim plugin and it was just... painful.
Onivim's vim emulation is great.. Because it's literally using libvim. It's also very snappy. But thats where the advantages end.
I'm surprised to hear this take. I've been a Doom Emacs user for a while, and while it was a bit more elbow grease to get it running on OSX, it was generally worth it for the speed/flexibility...
until
I ran into a non-trivially large Terraform code base. Slowed.to.a.crawl.
On the other hand, even with multiple plugins, VSCode was(and continues to be) very snappy. Nearly instantaneous search and motion.
I'm sure at least one time spacemacs was partly to blame (aka ALL THE THINGS activated/installed) - but it's definitely a difference in "feel" where (Neo)Vim feels closer to vi, and emacs feel closer to vs code/Atom.
Did you ever spend any time debugging what the issue was by any chance? Even with lsp enabled, I wasn't very impressed with any of the features it gave me (emacs or even in vscode)
Well if you are used to IDEs that also had that kind of lag...
I don't consider LSP to be a monolith. You still have the decentralization of language server development. Rather, LSP is just a standardization of what we have come to expect from editors interacting with plugins. And because the standard is modular in its features, the barrier to entry for new language servers and editors remains low.
As a standard, I don't think LSP encourages monopolization the way that the web does for browsers.
Yeah, perhaps this does make neovim more a monolith, as there are already great plugins like coc.nvim that can be used. However, I believe the expectations of a modern text editor have been raised sufficiently in the last few years that we now expect to have code intelligence baked in, just like we came to expect baked-in syntax highlighting decades ago over editors that lacked it back then.
And given the extensible core of neovim, if a better LSP-like system comes along someone will build a plugin to integrate it. Before this native LSP support there was (and still is) an excellent vim/neovim addon coc.nvim that adds LSP support using nodejs as a process manager for example.
LSP is very anti-monolith by design. Each language has its own little microservice LSP server that communicates to the editor using json-rpc. Everything can be swapped out and replaced dynamically--nothing is linked together or a direct dependency.
My data is purely anecdotal but I've noticed a correlation: people who spend the added time to configure their editor (be it vim or vscode) tend to be better at using their editor. It naturally follows that the time spent configuring it leads to a better understanding (and better recall) of how it works.
In my mind, the big "omnibus" plugin bundles for (n)vim prevent that understanding just as much as a default vscode config does [1].
[0]: Either by adding a plugin or, in most cases, by incorporating what I want into (n)vim's existing systems.
[1]: And no judgement for that -- not everybody has time or patience to deeply learn every tool they use.
i've been using vim for 10+ years. i tried vsc with a vim extensions and it's just not the same. maybe it's just because i'm super used to my vim config, but vsc + vim plugin feels so awkward and slow.
Sure, it’s worth considering…
> It’s not vim, it uses a shit ton of memory, and you can’t run it in the terminal
You just answered your own question on why it’s not necessarily a good idea ;-)
For text/file searching there's fzf + rg + fdfind
All these tools integrate with eachother but are already great on their own.
With nerdtree and other alike plugins you lock yourself into building IDE out of vim. With these specialized tools you can reap their benefits even without launching vim.
From my understanding, it’s also an opt-in feature, so you are free to use anything other language client or no language client at all.
But I agree with you that Neovim is gradually becoming more monolithic (though I believe it’s still very snappy and light). I’m pretty happy about it, though.
LSP is not going anywhere. Nor has it been here just for a "couple of years". It's here for over 5 years already.
Plus, the rest of the application is becoming increasingly modular, not less so.
While LSP is great, it basically came from nowhere in the last couple of years. My concern: what if something definitively better comes along in another couple years, and we're "stuck" with this baked into the editor?
For context, using ALE, I've been able to gracefully migrate my language-specific helpers from pre-LSP to post-LSP universes, over the years as LSP helpers have become definitively better and faster, one language at a time, all without needing to recompile or download a new binary.
I'm very open to the idea that I'm missing something obvious, because I have a lot of respect for neovim and neovim contributors. I understand that neovim is not trying to replace vim but evolve it. This feels like a move away from plugins and into monolith territory, which feels like a big step. Curious to hear other's thoughts.
To be clear, I'm not for or against this, I'm mostly curious about the reasoning / thinking behind this, if anybody has links I'd love to read them.