5 ms·

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.

vyskocilm 6y ago
I personally prefer https://github.com/dense-analysis/ale 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-tools.md https://github.com/dense-analysis/ale/blob/master/supported-...
- tylerscott 6y ago
  +1 for Ale. It has simplified my Vim life.
- f00zz 6y ago
  I've been using syntastic [1] for this. No server needed. [1] https://github.com/vim-syntastic/syntastic https://github.com/vim-syntastic/syntastic
- glennvtx 6y ago
  Same here
- gen220 6y ago
  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 6y ago
    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 6y ago
      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.
      - colordrops 6y ago
        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 6y ago
        > 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 6y ago
        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 6y ago
        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.
gkfasdfasdf 6y ago
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.
durandal1 6y ago
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 6y ago
Neovim 0.5 (not released yet but has PPA) has a builtin LSP client that not depends on NPM. It works very well.
- scruple 6y ago
  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 https://neovim.io/doc/user/lsp.html
- richchurcher 6y ago
  That's great! Thanks for mentioning this.
nikki93 6y ago
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.
yearoflinux 6y ago
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 6y ago
  I thought it was obvious... vim is lighter than qt creator is lighter than node.js + vim
jswny 6y ago
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.
nobleach 6y ago
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 6y ago
  >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 6y ago
    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 6y ago
    > 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.
bee_rider 6y ago
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.

vyskocilm 6y ago

I personally prefer https://github.com/dense-analysis/ale 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-tools.md https://github.com/dense-analysis/ale/blob/master/supported-...

tylerscott 6y ago
+1 for Ale. It has simplified my Vim life.
f00zz 6y ago
I've been using syntastic [1] for this. No server needed. [1] https://github.com/vim-syntastic/syntastic https://github.com/vim-syntastic/syntastic
glennvtx 6y ago
Same here
gen220 6y ago
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 6y ago
  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 6y ago
    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.
    - colordrops 6y ago
      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 6y ago
        > 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 6y ago
        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 6y ago
        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.

gkfasdfasdf 6y ago

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.

durandal1 6y ago

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 6y ago

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

scruple 6y ago
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 https://neovim.io/doc/user/lsp.html
richchurcher 6y ago
That's great! Thanks for mentioning this.

nikki93 6y ago

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.

yearoflinux 6y ago

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 6y ago
I thought it was obvious... vim is lighter than qt creator is lighter than node.js + vim

jswny 6y ago

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.

nobleach 6y ago

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 6y ago
>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 6y ago
  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 6y ago
  > 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.

bee_rider 6y ago

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.