[ducktective]

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

[elpatoisthebest]

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]

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]

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.

[CameronNemo]

This has not been my experience. For example I use this python language server, which is implemented in Python and uses jedi:

https://github.com/python-lsp/python-lsp-server

Rust analyzer is written in Rust, gopls in Go, clangd in C++, R language server in R, Jsonnet language server in Go, sqls in Go.

[ducktective]

> 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`

[mikewhy]

> and many other tie-ins like completion, snippets, formatting, and things like auto-pairs

This is usually where I check out when I get the urge to redo my vim setup. The fact that completion, auto pairs, snippets, and something like endwise are all at odds with each other isn't something I want to deal with.

[mjlbach]

> completion, snippets

This is fine in the nvim-cmp world, there's a config example in the lspconfig wiki, it's about 5 lines for the integration. The recommended lspconfig configuration (included snippets and autocompletion) has less lines of code than the example in the readme for coc.

> formatting

This is built-in to neovim's LS client (vim.lsp.buf.formatting()), adding an external formatter can be done with formatexpr (built-in)

[blindseer]

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.

[mjlbach]

> 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.

[petepete]

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]

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]

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.

[canaus]

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]

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]

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]

Same for me, coc.nvim community is rock solid whereas native LSP requires more configuration and is much less reliable version-to-version

[mjlbach]

> 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]

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.

[lc9er]

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]

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.

[CameronNemo]

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