Hacker News Reader

Comment by fredsanford | Hacker News Reader

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.

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.

>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

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.

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

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.

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

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

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

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

Same here

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]

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.

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.

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

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.

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.

Note that clangd is not a "blessed" implementation of a language server–there are others.

> The beauty of ale plugin is that it supports almost anything from scratch

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.

coc.nvim does a lot more than linting. I know ale tries to do completion but in practice I just found the experience of using coc to be really good. It's a bunch of little things that add up. Not sure what best way to convey it -- maybe a gif? Haha. I included an example screenshot of hover type info for example. Super useful esp. as languages like C++ and Go and TypeScript have type deduction/inference. I just put cursor on a symbol and do ';h' to get type info and maybe docs. And so on and so forth.

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.

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.

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.

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.

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.

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

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

That's great! Thanks for mentioning this.

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

I thought it was obvious...

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

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.

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.

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.

Reply on news.ycombinator.com