Is anybody else uncomfortable about the idea that an LSP client is now baked into the editor (as opposed to being a plugin)? Are there big performance gains to this approach?
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.
I'll give you my perspective (I'm just an average user):
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".
> Putting the onus on plugin writers to rewrite essentially the same functionality is not ideal.
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.
Emacs does not have the same problem. When you install a plug-in it will install the dependencies as well.
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.
Emacs nowadays have package management. And doom emacs is even better in that, because the management is declarative (you have a file with all your packages and it installs them and their dependencies)
ALE is amazingly useful even for curmudgeonly old timer Vim users. My one gripe is that I want the warnings to disappear once I begin modifying the buffer, which I have achieved. Can post the relevant part of my vimrc if desired.
I also use ALE, and my main reason not to switch is that I also want to run linters, and I don't want to install a separate linter plugin when I know ALE works just fine for me.
It would be interesting if ALE could integrate with nvim's LSP implementation though, although I'm not sure how that would work.
I have been an nvim user for the past few years now. I tried the whole modern nvim experience with Telescope, built in LSP and other Lua based extensions.. My conclusion is that my current setup with Ale, FZF + silver searcher, clangd/pylint and Deoplete is way faster, less buggy, albeit harder to setup.
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
VS Code is an awful editor in general. I don't understand how it's so popular. Maybe it's just me but I don't like having 300ms lag between every action I perform on my editor. The vim emulation is a joke.
Onivim's vim emulation is great.. Because it's literally using libvim. It's also very snappy. But thats where the advantages end.
> VS Code is an awful editor in general. I don't understand how it's so popular. Maybe it's just me but I don't like having 300ms lag between every action I perform on my editor.
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.
FYI the few times I've half-earnestly tried emacs+evil one of the reasons I've gone back to (neo)Vim is that emacs feels sluggish.
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.
Doom emacs has a focus on speed that spacemacs just doesn't have. It's similar enough to spacemacs that it is easy to pick up if you got used to spacemacs at all. I'd recommend trying it out and see how it feels.
I spend well over half of my time in Terraform repos. I've also noticed doom emacs slowing down considerably whenever using the terraform-ls so I have lsp disabled for terraform.
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)
> This feels like a move away from plugins and into monolith territory, which feels like a big step.
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.
It's not enabled by default, you have to install language servers and turn them on one by one.
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.
I would actually LOVE to see VIM with NerdTree, File/text searching, lsp and first class git support baked in and integrated well without need of tuning something in your .vimrc file every weekend.
I know it sounds snarky, but at some point of vimrc complexity it’s worth considering just switching to vscode with the vim extension. It can use neovim as a back end and you get mountains of features out of the box. I created vim-idiomatic key mappings to all the vscode features and extensions I commonly use. It’s not vim, it uses a shit ton of memory, and you can’t run it in the terminal, but I love it. For context, I was formerly a vim snob for 10 years. I’m also mainly a typescript guy so YMMV.
I don't see this often talked about, but some of the biggest value that (n)vim provides for me is that I've configured it myself. I know what's in my .vimrc because I'm the one that put it there. It takes me longer to add new features [0], but once it is set up how I want it, I understand it more deeply.
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 know it sounds snarky, but at some point of vimrc complexity it’s worth considering just switching to vscode with the vim extension.
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.
Another nice aspect of Neovim 0.5 is that you can do the entire configuration in Lua, so you can break out your config into multiple files and have things more organized and compartmentalized.
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.
I actually started using Neovim builds from master to get access to built in LSP before this release. It’s faster and lighter weight than any other LSP client I’ve used (I have used vim-lsp and languageclient-neovim in the past).
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.
>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?
LSP is not going anywhere. Nor has it been here just for a "couple of years". It's here for over 5 years already.
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.