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.

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

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.

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`

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.

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)

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.

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.

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.

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.

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

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.