6 ms·

People who have tried both vim and nvim: - I have a theory that using `coc.nvim` is still the superior solution even compared to a native LSP. Why? Cause we ca

People who have tried both vim and nvim: - I have a theory that using `coc.nvim` is still the superior solution even compared to a native LSP. Why? Cause we can siphon from the huge man-hours of development and polish that M$ has put on VSCode. Every time they tweak VSCode, we at downstream, enjoy the benefits. Am I wrong in my assessment? - Vim's regexp-based syntax highlighting is annoying. So I think nvim+tree-sitter is the better solution on this front

blindseer 5y ago
I’m not sure if CoC.nvim is necessarily superior. CoC.nvim, VSCode, and all the other nvim lsp plugins use the same LSP servers. The clients are all different obviously, and I don’t think there’s any major features in CoC.nvim that aren’t in neovim’s built in LSP. I’d be curious if someone has a more comprehensive answer for this. I use the built in LSP and have been perfectly happy.
petepete 5y ago
I like both COC and CMP (native). COC is way easier to set up and the default config is fine. CMP is lighter and more configurable, and it works really nicely with luasnip (my snippet engine of choice). Under the hood they both use the same LSPs, but COC pulls them down and sets them up for you.
- sreevisakh 5y ago
  Theoretically, we could build a plugin that does all automatic setup like COC, but then uses the built-in LSP to do the actual work. nvim-lspconfig already does part of this job - configuring the LSP, as long as the server is already installed. Personally, I prefer the system package manager taking care of the servers, rather than yet another package maintenance system.
  - mjlbach 5y ago
    lspconfig maintainer here, minor info dump: Lspconfig currently has 3 parts, the default settings for the servers, an implicit project detector to trigger when to launch the servers (conditioned on filetypes and some patterns), and the infrastructure to manage launching/shutting down/attaching buffers to servers as you open files within the same project. Eventually we'd like parts 2 & 3 to be in core as a "projects" module, leaving separate "project patterns" and "server settings" as mostly metadata containing repositories. That would open the door for third party plugins to create customized project templates which map keybindings, set formatexpr, pass custom server settings, etc. similar to how coc.nvim has coc-pyright, coc-gopls, etc. These plugins could also handle installing language servers automatically should they choose to offer that. There's also nvim-lsp-installer, but I really don't like the approach it takes of hijacking lspconfig's setup.
lc9er 5y ago
I agree with your coc.nvim assessment. It’s more cohesive and works pretty much out of the box. You have to assemble more plugins to recreate the functionality coc provides as a whole and the documentation on the config process is sparse (as of my last attempt to use it). I’m also probably a weird edge case in that my primary use case is writing Powershell. Coc just works and getting native LSP configured and working requires more time than I’ve been willing to give it.
- mjlbach 5y ago
  If you're having a powershell issue, you can file an issue. I'm not a Windows user or powershell user, but when I tested the PR (before merging it) I was able to get it running in a minute.
elpatoisthebest 5y ago
I do recommend that new users just use coc.nvim, but not exactly because of what you said. Both coc.nvim and the built in LSP implementation use basically the same Language Servers, so whatever updates happen to the server will benefit either approach. However, coc.nvim DOES have a large community that has built a neatly packaged LSP client framework (and many other tie-ins like completion, snippets, formatting, and things like auto-pairs) that is a much more cohesive experience. The built in LSP is best at providing a solid baseline client for those language servers if you really want to tweak everything to exactly how you want it. If you like that approach where you don't want to configure everything yourself, coc.nvim is probably the "superior" approach for you. If you have ever said the word "bloat" unironically on your computer with 64G of RAM, built in might be for you.
- CameronNemo 5y ago
  If you have ever said the word "bloat" unironically on your computer with 64G of RAM, built in might be for you. I really just want one config that works on: * Yes, my Ryzen 5 with 32G of RAM * My Pinebook Pro with 4G of RAM (and like 3.7G accessible) (and limited storage as well) * My jump host / gateway VM with 512MB of RAM (and even more limited storage than the PBP) So pulling down and running node.js to use coc.nvim has never been something I was interested in. Before nvim-lspconfig I used LanguageClient-neovim (a Rust client).
  - qbasic_forever 5y ago
    A lot of LSPs are written for node though, like pyright for example (yes, the best python LSP is written in typescript). It's kind of unavoidable to use node at some point if you're using LSPs in your editor.
    - ducktective 5y ago
      > It's kind of unavoidable to use node This. Learned it the hard way. For many moons, I tried integrating YouCompleteMe and the like. Then one day, I just gave up and switched to `coc.nvim`
canaus 5y ago
I came from coc.nvim and switched to the native LSP when it was released on nightly. For a while I was using VSCode and came back to nvim and switched back to coc.nvim. I found that the native LSP's community to be too quickly changing. Plugins that were necessary earlier weren't, while new necessary plugins came into play. But, coc.nvim was steady chugging along and my old settings file worked out of the box. I'm also not a huge fan of just the sheer amount of plugins that use the LSP. It seems like every plugin has go-to functionality.
- qbasic_forever 5y ago
  Yeah autocompletions are a mess with native LSP. In the last 6 months or so there have been ~3 different plugins around to support autocompletion, and each one fell into unmaintained or unused status. I hope eventually there is a stable, native solution for it.
  - mjlbach 5y ago
    nvim-cmp has been the dominant plugin for about a year now, and I keep the lspconfig wiki (mostly) up to date +/- a few days if anything changes
- imbnwa 5y ago
  Same for me, coc.nvim community is rock solid whereas native LSP requires more configuration and is much less reliable version-to-version
  - mjlbach 5y ago
    > is much less reliable version-to-version Source? We have an extremely extensive test suite for the built-in client that must pass for every merge, and we currently have ~30 open issues on the issue tracker (with a good chunk of those being feature requests).
    - bendavis381 5y ago
      Yeah I can second this. I've been using native LSP since 0.5 nightly and it's been nothing but solid. The only thing that occasionally gave me issues were tree-sitter crashes (unrelated to LSP), but even those seem to have all been fixed by now.
CameronNemo 5y ago
you may be interested to know: https://news.ycombinator.com/item?id=31041616 https://news.ycombinator.com/item?id=31041616
mjlbach 5y ago
> Cause we can siphon from the huge man-hours of development and polish that M$ has put on VSCode. Anything done on the language server side is already coc/built-in client agnostic (since communication is done over json-rpc, except for tsserver which MS has not yet exposed via the LSP, so we rely on the typescript-language-server-wrapper), anything on the client side is marginally useful at best.

blindseer 5y ago

I’m not sure if CoC.nvim is necessarily superior. CoC.nvim, VSCode, and all the other nvim lsp plugins use the same LSP servers. The clients are all different obviously, and I don’t think there’s any major features in CoC.nvim that aren’t in neovim’s built in LSP. I’d be curious if someone has a more comprehensive answer for this. I use the built in LSP and have been perfectly happy.

petepete 5y ago

I like both COC and CMP (native). COC is way easier to set up and the default config is fine. CMP is lighter and more configurable, and it works really nicely with luasnip (my snippet engine of choice). Under the hood they both use the same LSPs, but COC pulls them down and sets them up for you.

sreevisakh 5y ago
Theoretically, we could build a plugin that does all automatic setup like COC, but then uses the built-in LSP to do the actual work. nvim-lspconfig already does part of this job - configuring the LSP, as long as the server is already installed. Personally, I prefer the system package manager taking care of the servers, rather than yet another package maintenance system.
- mjlbach 5y ago
  lspconfig maintainer here, minor info dump: Lspconfig currently has 3 parts, the default settings for the servers, an implicit project detector to trigger when to launch the servers (conditioned on filetypes and some patterns), and the infrastructure to manage launching/shutting down/attaching buffers to servers as you open files within the same project. Eventually we'd like parts 2 & 3 to be in core as a "projects" module, leaving separate "project patterns" and "server settings" as mostly metadata containing repositories. That would open the door for third party plugins to create customized project templates which map keybindings, set formatexpr, pass custom server settings, etc. similar to how coc.nvim has coc-pyright, coc-gopls, etc. These plugins could also handle installing language servers automatically should they choose to offer that. There's also nvim-lsp-installer, but I really don't like the approach it takes of hijacking lspconfig's setup.

lc9er 5y ago

I agree with your coc.nvim assessment. It’s more cohesive and works pretty much out of the box. You have to assemble more plugins to recreate the functionality coc provides as a whole and the documentation on the config process is sparse (as of my last attempt to use it). I’m also probably a weird edge case in that my primary use case is writing Powershell. Coc just works and getting native LSP configured and working requires more time than I’ve been willing to give it.

mjlbach 5y ago
If you're having a powershell issue, you can file an issue. I'm not a Windows user or powershell user, but when I tested the PR (before merging it) I was able to get it running in a minute.

elpatoisthebest 5y ago

I do recommend that new users just use coc.nvim, but not exactly because of what you said. Both coc.nvim and the built in LSP implementation use basically the same Language Servers, so whatever updates happen to the server will benefit either approach. However, coc.nvim DOES have a large community that has built a neatly packaged LSP client framework (and many other tie-ins like completion, snippets, formatting, and things like auto-pairs) that is a much more cohesive experience. The built in LSP is best at providing a solid baseline client for those language servers if you really want to tweak everything to exactly how you want it. If you like that approach where you don't want to configure everything yourself, coc.nvim is probably the "superior" approach for you. If you have ever said the word "bloat" unironically on your computer with 64G of RAM, built in might be for you.

CameronNemo 5y ago
If you have ever said the word "bloat" unironically on your computer with 64G of RAM, built in might be for you. I really just want one config that works on: * Yes, my Ryzen 5 with 32G of RAM * My Pinebook Pro with 4G of RAM (and like 3.7G accessible) (and limited storage as well) * My jump host / gateway VM with 512MB of RAM (and even more limited storage than the PBP) So pulling down and running node.js to use coc.nvim has never been something I was interested in. Before nvim-lspconfig I used LanguageClient-neovim (a Rust client).
- qbasic_forever 5y ago
  A lot of LSPs are written for node though, like pyright for example (yes, the best python LSP is written in typescript). It's kind of unavoidable to use node at some point if you're using LSPs in your editor.
  - ducktective 5y ago
    > It's kind of unavoidable to use node This. Learned it the hard way. For many moons, I tried integrating YouCompleteMe and the like. Then one day, I just gave up and switched to `coc.nvim`

canaus 5y ago

I came from coc.nvim and switched to the native LSP when it was released on nightly. For a while I was using VSCode and came back to nvim and switched back to coc.nvim. I found that the native LSP's community to be too quickly changing. Plugins that were necessary earlier weren't, while new necessary plugins came into play. But, coc.nvim was steady chugging along and my old settings file worked out of the box. I'm also not a huge fan of just the sheer amount of plugins that use the LSP. It seems like every plugin has go-to functionality.

qbasic_forever 5y ago
Yeah autocompletions are a mess with native LSP. In the last 6 months or so there have been ~3 different plugins around to support autocompletion, and each one fell into unmaintained or unused status. I hope eventually there is a stable, native solution for it.
- mjlbach 5y ago
  nvim-cmp has been the dominant plugin for about a year now, and I keep the lspconfig wiki (mostly) up to date +/- a few days if anything changes
imbnwa 5y ago
Same for me, coc.nvim community is rock solid whereas native LSP requires more configuration and is much less reliable version-to-version
- mjlbach 5y ago
  > is much less reliable version-to-version Source? We have an extremely extensive test suite for the built-in client that must pass for every merge, and we currently have ~30 open issues on the issue tracker (with a good chunk of those being feature requests).
  - bendavis381 5y ago
    Yeah I can second this. I've been using native LSP since 0.5 nightly and it's been nothing but solid. The only thing that occasionally gave me issues were tree-sitter crashes (unrelated to LSP), but even those seem to have all been fixed by now.

CameronNemo 5y ago

you may be interested to know: https://news.ycombinator.com/item?id=31041616 https://news.ycombinator.com/item?id=31041616

mjlbach 5y ago

> Cause we can siphon from the huge man-hours of development and polish that M$ has put on VSCode. Anything done on the language server side is already coc/built-in client agnostic (since communication is done over json-rpc, except for tsserver which MS has not yet exposed via the LSP, so we rely on the typescript-language-server-wrapper), anything on the client side is marginally useful at best.