I personally prefer https://github.com/dense-analysis/ale plugin. It is in vimscript and supports almost everything (including clangd) out there: https://github.com/dense-analysis/ale/blob/master/supported-...
I don't understand why coc.vim is so popular, when Ale is so performant and "debuggable" (i.e. produces useful performance traces).
[long-time ale user here, I don't use clangd but I do use python-language-server, which is similar]
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.
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.
I'm trying to see if I'm missing something big/obvious, since coc.vim has been so popular recently.
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.
I use Vim not for philosophical or cultural reasons but because I enjoy the UX.
CoC's autocompletion is much more advanced than Ale. I used Ale for years.
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).
let g:deoplete#enable_at_startup = 1
call deoplete#custom#option({
\'auto_complete_delay': 1000,
\'sources': {
\ '_': ['ale', 'buffer'],
\ 'py': ['ale'],
\}
\})
It is possible that coc.vim can do better. But I can't imagine how much better it should have be.
this has been my experience too.
I was editing some prolog the other day, `:ALEInfo` recommended swipl. worked like a charm!
the linters covered are quite incredible: https://github.com/dense-analysis/ale/tree/master/ale_linter....
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.