[gen220]

Is there some feature that coc.vim has that ale does not? Can someone explain coc.vim's popularity to me?

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]

[jswny]

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.

[gen220]

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.

[nikki93]

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.

[gen220]

Sorry if I came across that way. Agree people should use the things they prefer. :)

I'm trying to see if I'm missing something big/obvious, since coc.vim has been so popular recently.

[nikki93]

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.

[colordrops]

Do you understand how Ale works?

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.

[gen220]

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

    let g:deoplete#enable_at_startup = 1
    call deoplete#custom#option({
        \'auto_complete_delay': 1000,
        \'sources': {
        \  '_': ['ale', 'buffer'],
        \  'py': ['ale'],
        \}
    \})

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

[colordrops]

CoC is built around the Microsoft Language Server. I wasn't able to get LSP working with Ale but perhaps things have changed since I switched.

[vyskocilm]

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.