Generally it's because Coc has completion, snippets, and pretty much everything from the regular VSCode version of the extension built-in, so Coc can replace multiple plugins, and it works very well.
Right, but Ale does this too (replace multiple plugins, supports completion, linting/formatting).
Is it that coc.vim doesn't make you install the binaries of the tools (i.e. go-pls, python-language-server, clangd)? If so, that would be enough to explain the popularity to me.
IMO, one could make the argument that it's somewhat antithetical to vim-culture, to not understand the non-vim binaries your editor is executing.
One thing I really like in coc is I can ask to describe a symbol and it'll tell me about it in a hover thing: https://i.imgur.com/NrH0Wwz.png
Do agree that coc is probably the least 'vim-culture'-ey part of such a setup, but hey it does good things. :) I don't think you need to justify using Ale so hard and put coc down, could just use whichever you prefer personally.
No worries! And yeah I went through a phase a few months ago of trying out the completion packages again, it's worth just trying and seeing if you like it. Here's the relevant bits of my config if that helps: https://gist.github.com/nikki93/6ea403d3e2cbff2b3d32d4528edf...
coc.nvim has pretty much worked pretty well out of the box for many languages, and it works for me on macOS, Linux and Windows.
> CoC's autocompletion is much more advanced than Ale
I thought that both are pass-throughs to other completion engines, so isn't this a moot comparison? (maybe coc integrates the completion engine, but it doesn't implement a new one, right?).
I use deoplete, but I'm not married to it (it's kind of slow when you have a big file).
If so, isn't the completion experience is strictly a function of the completion engine you're passing coc/ale into (ux), and the binaries that you're passing into coc/ale (completion options)?
Microsoft Language Server is a protocol. It's up to each language to have own , blessed implementation like clangd, solargraph, or gopls. The beauty of ale plugin is that it supports almost anything from scratch and as I work on a multi language projects all the time it rocks everywhere. Do you have prettier installed? Boom all your JS files are checked. Do you have gopls, gofmt, goimports? Then yeah, you can use all of those from your editor. And so on. I am usually surprised how many linters it supports. Recently I got hints when editing protobuf file. Did not expected it.
It is possible that coc.vim can do better. But I can't imagine how much better it should have be.
I do a lot of JavaScript dev, and LSP is bar none the best in class. I can jump around to variable and class definitions and do minor refactoring almost like it was C++. If Ale supports it then great. I don't care which system is used as long as it supports LSP reliably.
And if you read each integration file, they are quite small and comprehensible. I've never needed to add one myself, but I feel like I could if I wanted to.
Is it that coc.vim doesn't make you install the binaries of the tools (i.e. go-pls, python-language-server, clangd)? If so, that would be enough to explain the popularity to me.
IMO, one could make the argument that it's somewhat antithetical to vim-culture, to not understand the non-vim binaries your editor is executing.