121–130 of 213 posts
In my experience, the built in LSP is a mixed bag. Getting language servers configured is a breeze, diagnostics and go-to definition work just fine. But trying to get autocomplete and snippets to work is an exercise in frustration. There's a handful of different hobbyist implementations which are all somewhat-maintained and somewhat work together but it's buggy and you end up needing to do 20x the effort of using VS…
In my experience, the built in LSP is a mixed bag. Getting language servers configured is a breeze, diagnostics and go-to definition work just fine. But trying to get autocomplete and snippets to work is an exercise in frustration. There's a handful of different hobbyist implementations which are all somewhat-maintained and somewhat work together but it's buggy and you end up needing to do 20x the effort of using VS…
For example I have to install 3 different plugins to get all the LSP UI so it means I have 3 different opinions on how various parts of its UI should look and it's a real mess--the popups for suggestions as I type are totally different looking compared to the popups to show function signatures (and each has their own bespoke way of being configured).
Earlier quoted context omitted.
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 l…
> 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.
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.
Earlier quoted context omitted.
Funny, I switched from neovim to VSCode + the vim plugin. Sure, it doesn't have everything I would do with vim supported, but it's enough and overall it's a better experience
I tried switching to VSCode with the vim plugin. but I got frustrated with vim keys that didn't quite work right on VSCode. And iirc configuring custom vim-style bindings was quite a pain. And then there were the neovim/vim plugins that I used that didn't have good equivalents in VSCode, especially that worked well with the vim plugin. Also VSCode is much, much more resource hungry.
vscode-neovim is designed for and requires neovim 0.5. I hate, hate, hated vscodevim but vscode-neovim is very good, very usable; I stopped using VSC altogether until vscode-neovim got real. It's not perfect, it still needs work on command mode, but it's quite usable. I even got rid of my other vims (MacVim, VimR, ...).
In my experience, the built in LSP is a mixed bag. Getting language servers configured is a breeze, diagnostics and go-to definition work just fine. But trying to get autocomplete and snippets to work is an exercise in frustration. There's a handful of different hobbyist implementations which are all somewhat-maintained and somewhat work together but it's buggy and you end up needing to do 20x the effort of using VS…
I have zero problems with nvim-compe [1], it works like a breeze. [1]: https://github.com/hrsh7th/nvim-compe
Once I added snippets and modified the completion code, the ability to hit "Enter" to select an autocompletion selection broke and I couldn't manage to fix it without preventing the key from entering a newline in insert mode. I ended up just remapping it to a new key. But even then, it's still a little quirky- if I type some text and hit tab expecting to add some spacing, I'd instead get prompted for autocomplete suggestions I wasn't looking for.
I get that all this is fun for some people, but I just want sane defaults that work like VS code.
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'v…
For anyone else wondering: • LSP means Language Server Protocol [0] • ALE means Asynchronous Lint Engine [1] [0] https://microsoft.github.io/language-server-protocol/ [1] https://github.com/dense-analysis/ale
Could someone sell me on why I should switch to this from regular Vim?
I'm probably a bad neovim reviewer though since I'm not really keen to try the LSP stuff. I wind up working in a lot of different languages and inevitably I feel like getting accustomed to completion working well in language A only to have it fail with B is more annoying than having no completion at all. I'm curious whether I'll wind up using anything which is only possible in neovim.
In my experience, the built in LSP is a mixed bag. Getting language servers configured is a breeze, diagnostics and go-to definition work just fine. But trying to get autocomplete and snippets to work is an exercise in frustration. There's a handful of different hobbyist implementations which are all somewhat-maintained and somewhat work together but it's buggy and you end up needing to do 20x the effort of using VS…
I have zero problems with nvim-compe [1], it works like a breeze. [1]: https://github.com/hrsh7th/nvim-compe
In my experience, the built in LSP is a mixed bag. Getting language servers configured is a breeze, diagnostics and go-to definition work just fine. But trying to get autocomplete and snippets to work is an exercise in frustration. There's a handful of different hobbyist implementations which are all somewhat-maintained and somewhat work together but it's buggy and you end up needing to do 20x the effort of using VS…
Yeah coc.nvim is a much better experience in my usage. I want to love the native LSP, but the hodgepodge of in-progress or abandoned completion, suggestion, signature, diagnostic, etc. UI is a big pain point right now. For example I have to install 3 different plugins to get all the LSP UI so it means I have 3 different opinions on how various parts of its UI should look and it's a real mess--the popups for suggestio…
One little-talked about advantage of Lua support is that you can now write your vim config/scripts in one of the various Lua transpilers like moonscript [0], or maybe even typescript [1]! [0]: https://github.com/leafo/moonscript [1]: https://github.com/TypeScriptToLua/TypeScriptToLua [2]: https://github.com/hengestone/lua-languages