[fredsanford]

Yeah, lets take lightweight vim and add a node.js runtime and make a better ide.... sigh

At that point you might as well use QT Creator.

[nobleach]

Some folks really like Vim more than "vim-mode" for any given editor. I don't see any problem here if no one is forcing you to use it. (It's not built in to Vim).

There are a ton of people that use Vim because it's productive, not because of how "lightweight" it is. I see no reason to shame people if they choose to use "heavy" plugins to achieve whatever functionality they want.

[Barrin92]

>There are a ton of people that use Vim because it's productive, not because of how "lightweight" it is. I see no reason to shame people if they choose to use "heavy" plugins to achieve whatever functionality they want.

because vim wasn't exactly built with these kinds of features in mind and it shows when you start to throw a lot of IDE features into vim. For example switching to very large text files with vanilla vim, doing some search and replace is no problem, it's super fast.

Doing that with the wrong plugin on that does some CPU heavy stuff can very quickly make vim unresponsive.

IDEs are already built with a rich feature set in mind, so you can expect performance to be relatively stable. Vim or Emacs with the entire kitchen sink thrown in tends to be a little bit dicy

[nobleach]

Perhaps. But since it's not main-lined into the actual application, it's no big deal. If people want to "pimp" their Vim with airline, and any other odd nonsense, that's fine. If they want to include an entire nodejs process to provide auto-complete, that's fine too. I'm simply saying that the fact that it was originally conceived as a lightweight text editor, doesn't mean that people should be shamed for making it so much more. I personally have found Vim to be my favorite tool, and nearly EVERY attempt at other IDEs to emulate it, I've found lacking. So, I choose to extend Vim.

[soraminazuki]

> because vim wasn't exactly built with these kinds of features in mind and it shows when you start to throw a lot of IDE features into vim.

I disagree. Both Vim and Neovim are under active development, and have acquired many features to support IDE functionality.

> For example switching to very large text files with vanilla vim, doing some search and replace is no problem, it's super fast.

This has improved a lot in the last few years thanks to the async APIs.

[gkfasdfasdf]

The CoC plugin mentioned (which uses node) isn't the only option - LanguageClient-neovim works great and is written in Rust (and works with vim or neovim despite the name), also the upcoming Neovim 5 will have built in support for language servers.

EDIT: Also, the actual language server (clangd, ccls, etc) which is compiling/reindexing your project behind the scenes is generally the most resource intensive part of the whole setup - so even CoC with node is not a bad choice.

[vyskocilm]

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

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

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

[f00zz]

I've been using syntastic [1] for this. No server needed.

[1] https://github.com/vim-syntastic/syntastic

[tylerscott]

+1 for Ale. It has simplified my Vim life.

[glennvtx]

Same here

[durandal1]

Have you tried it? Using CoC with neovim, neovim is instantly responsive, the only delay is that it takes a few secs for some of the CoC LSP services to be available until the language server is launched and ready. The typing experience is not impacted at all.

[figomore]

Neovim 0.5 (not released yet but has PPA) has a builtin LSP client that not depends on NPM. It works very well.

[scruple]

Is there somewhere that I can read more about this? I tried checking neovim.io and the repo but wasn't able to find anything.

edit/ Of course, Google was able to pop it out after I submit this comment... For anyone else who may be curious about how this works: https://neovim.io/doc/user/lsp.html

[richchurcher]

That's great! Thanks for mentioning this.

[yearoflinux]

Qt creator is 100 MB and starts in 3 seconds. Why do you (even favourably) compare it to node?

Also, qtcreator is pretty darn good for Rust too

[fredsanford]

I thought it was obvious...

vim is lighter than qt creator is lighter than node.js + vim

[jswny]

I'm also not personally a fan of the model that Coc takes (although it is impressive tech).

Besides adding a Node dependency, Coc extensions are basically ported VSCode extensions with some changes necessary to make them work with Coc. This means that for every single extension you want to port to Coc, someone has to maintain a Coc fork and keep up with the upstream VSCode extension.

Personally, I just don't feel that this is sustainable.

[nikki93]

It's actually quite good and runs super smoothly on my Chromebook, where VSCode was slow. I like keeping all of my vim stuff while also getting this.

[bee_rider]

Since this is a client-server setup, hopefully the heavy weight stuff is outside the keyboard->computer->eyeball critical path. So it should still be the nice, tight user experience associated with lightweight editor. You just have some node.js process hanging out there in your many spare megabytes of ram, occasionally sending you things.