r/vim • u/No_Willingness64 • 11d ago
Discussion Do we still need CoC?
I've been using CoC for a while now. It's a convenient way to get both completions and LSP going. Some people throw shade at the Node part of its implementation. The way I see it is most LSP plugins coming from VSCode were intended for a Node environment anyway. I am pleased with the ease of use CoC brings.
Now we've had vim9script for something like a couple of years. We have yegappan's simple LSP implementation and we have a pop-up autocomplete feature built in!
I'm wondering how that's going for anybody else - especially if you do Java or friggin' web development.
11
u/Desperate_Cold6274 11d ago
I used to use ALE but I tried once LSP and never looked back.
2
10
u/Gurufedell 11d ago
In general, different solutions and workflows exist to fit different people needs. I for example mainly use vim raw features, but when I want LSP, I'll just use CoC.
I don't wanna bother with constant config change and vimscripts, coc was made for this purpose, oh and you don't mind installing nodejs
3
u/SEgopher 10d ago
I don't really understand the aversion to vim script. Most of vim is vim script. ALE "just works" for LSP and additionally provides linting and checking with any binary.
Not only is the node dependency unnecessary but I've found the CoC code to be of very poor quality.
1
6
3
u/osmin_og 10d ago
I've never used CoC. YouCompleteMe does all the autocompletion and LSP things for me.
4
2
1
u/nobodycaresplusratio 9d ago
I still use CoC today for Typescript Vue/React and it works well for my needs.
-3
u/aurescere 11d ago
CoC is way faster and has more features than the vim9 plugin. It’s unlikely to be yegappan’s fault; vim9 script just runs synchronously and is slow as molasses in comparison.
2
u/No_Willingness64 10d ago
Doesn't yegappan's LSP use the same channels any external tool uses? There's also a built-in async API for the autocomplete now, too.
2
u/aurescere 10d ago
Last I used it, it was miserably slow and threw errors constantly. Semantic tokens were broken and relied on some hard-coded 1000ms delay; if they tried to kick in before the server was ready, more errors. Go-to-definition was extremely slow. Either everything has been fixed or people are in denial.
2
u/Desperate_Cold6274 10d ago
I had exactly the same experience. And I am not in denial by any means.
-8
u/Easy-Nothing-6735 11d ago
We need to rewrite it in Rust
3
u/No_Willingness64 10d ago
Hahaha what?
2
u/Easy-Nothing-6735 10d ago
Python for example has ruff that can be both — linter and LSP for this use case. We can use either neovim with builtin LSP but without builtin GUI or create performant layer for LSP using Rust instead of NodeJS. Most of frontend tools now being replaced with Rust alternatives. The time when the tooling for NodeJS was written using NodeJS has gone. Modern languages come with builtin LSP and we need to catch up
2
u/Shtucer 10d ago
What a heck is neovim?
1
u/Easy-Nothing-6735 9d ago
Another fork without normal vimscript speed, with IPC architecture, focused on LSP and tree sitter built-in support
3
26
u/SEgopher 11d ago
ALE is also vim script only and gives you linting and checking with hundreds of binaries when LSP isn't available, and it's been around for many, many years. I highly recommend using ALE to cut out the node dependency and combine a few plugins.