Thoughts and questions on :CocInstall

[svenstaro]

First of all let me state that this is a very cool project and I'm currently trying to reconfigure my vim to use coc.nvim. That said, I think it's a bit awkward having to use two different package managers inside of my vim. I use vim-plug but I now also have to use CocInstall and sometimes they even overlap.

I thought ok, maybe use CocInstall only for forked vscode addons, but then there is also coc-pairs (for instance) which is a more general purpose plugin that doesn't have anything to do with async completion. So I'm wondering whether we'll really have to use two package managers at the same time inside of vim? Isn't there a way to use vim-plug to declare coc.nvim extensions?

Maybe we can get rid of CocInstall altogether then?

I'm really just a bit confused as to how these two package managers play together and how their ecosystem will progress. I'd prefer having just one package manager (and vim-plug is pretty good).

Anyway, these are just my thoughts. Keep doing your great project!

[chemzqm]

Unlike vim plugins, coc extensions are node modules that can be loaded by coc.nvim.

So why use coc extensions?

Here're some reasons:

• To install a coc extension all you need is run :CocInstall command, when finished, it's loaded and just works.
• Configure coc extension in coc-settings.json with completion and diagnostic support by coc-json.
• Easier managed by :CocList extensions with actions like toggle reload and uninstall.
• Automatically updated every day the first time you start coc.nvim service by default.

None of coc extension is required for coc.nvim to work, it's designed to work with other vim plugins, so you can simply ignore coc extension when you don't like it for whatever reason.

You can also use g:coc_global_extensions in vimrc to make coc.nvim install extensions for you when extension not found.

[svenstaro]

I see your reasoning and here is mine:

• Having only a single plugin manager is less mental overhead.
• Having only the vimrc (as opposed to additionally having coc-settings.json is also less mental overhead.
• There is some overlap between "normal" vim plugins and CoC vim plugins which feels wrong to me. For instance, what does coc-pairs do that a "normal" vim plugin can't do (honest question I'd like the answer to).

[chemzqm]

It's possible to make coc.nvim load extensions from &rtp, so you can use plugin mangaer like vim-plug to manage coc extensions. Should be easy to implement but as I have mentioned, you will be missing some nice features that coc.nvim can provide.

You can use g:coc_user_config instead of coc-settings.json for configuration if you don't care features like autocomplete and validation.

There is some overlap between "normal" vim plugins and CoC vim plugins which feels wrong to me.

So make your own descision, I've explained why they exists.
IMO, compare to the benefit provided by coc extension, the overhead can be ignored.

[pvonmoradi]

Thanks for your amazing works developing coc.nvim.
How to make coc configs portable? I mean how to reinstall the coc packages in another machine? For vim, we only need to move .vimrc.

[Kuxe]

Thanks for your amazing works developing coc.nvim. How to make coc configs portable? I mean how to reinstall the coc packages in another machine? For vim, we only need to move .vimrc.

According to coc.nvim wiki it's possible to write:

let g:coc_global_extensions = ['coc-json', 'coc-git']

I just tested this out and it works as expected on NVIM v0.5.1.

[chemzqm]

Or use plugin manager to install coc extensions from github.