Use blink.cmp over nvim-cmp?

[makew0rld]

Thanks for creating Kickstart, it's been a great way for me to start using Neovim for the first time.

One of the only things I've noticed missing is getting function signatures to appear when I'm typing the arguments of a function. I was eventually able to solve this using mini.completions, but when I posted about this on Reddit people suggested using blink.cmp which I hadn't heard of before.

Do you have any thoughts on blink and using it in Kickstart?

[feoh]

My thoughts are that blink-cmp looks interesting but that I do not understand Neovim completion well enough to undertake the transition.

Pull requests always welcome!

[bluz71]

Blink ships a Rust compiled library whilst nvim-cmp is pure Lua. Pure Lua plugins will have lower maintenance overhead in the long run.

nvim-cmp used to have poor performance with Tailwind LSP, however a recent commit resolved that issue.

I compared completion performance between the two recently and could not see any obvious difference.

I suggest be conservative for now.

[iSolate77]

Agree with sticking to nvim-cmp. While I've used blink for the past few weeks. As a kickstarter kit, it's better to have a more stable plugin like nvim-cmp, instead of the actively developed blink, which could introduce breaking changes.

[sarmong]

Agree with sticking to nvim-cmp, but keeping an eye on blink and switching to it when the stable release is published. Mainly for the reason of it being simpler to use, because nvim-cmp may be tricky to configure even for advanced neovim users.

[feoh]

Thanks for the feedback all! Let's collectively keep an eye on things and switch when it makes sense :)

I do like the idea that blink bundles a lot of things we currently have to explicitly configure in by default.

I think long term, shrinking kickstart's code size would be hugely beneficial in the mission of helping folks get started in an understandable way.

[rfletchr]

cmp can display signatures, it needs them added as a source.

I'll make a PR

[rfletchr]

@makew0rld #1358

That'll get you going.

I think you should still explore blink. I personally prefer it to cmp.nvim. I do also think that the choice to use a pure lua solution is sound. Introducing compiled dependencies always adds complication. Rust is no exception.

[feoh]

Yeah I'm exploring a brand new non kickstart config for my personal use and I'm auditioning blink. So far I really like it!

However to everyone's point, on WSL I did need to run a cargo build to generate the binary. "Install the Rust toolchain and run..." is probably not the welcome we want to give our Neovim newbies :)

I'm sure these rough edges will get ironed out over time. I do think blink represents an evolutionary step over cmp.

[RiteshChepuri]

I used blink for my config and it works great in some cases, But Blink is still in some what development in some aspects and doesn't have additional sources which nvim cmp already has ( yes we can use plugins to integrate them with blink).

I think kickstart should have nvim cmp until blink becomes more stable and has a lot of sources by default for short term.

But in Long term we should adapt to blink as it reduces the code base by a lot and has a lot of performance benefits over nvim cmp

[feoh]

Agreed on all counts.

[bluz71]

I still believe that the Rust build chain is a complication that kickstart.nvim should avoid. I do note that pre-compiled blink binaries are offered for some platforms & releases. But as a Linux user I once had blink build it's library (via my installed Rust) rather than use the pre-compiled binaries; I don't know why.

An alternate strategy is to avoid nvim-cmp vs blink debates and instead migrate to the upcoming Neovim 0.11 builtin LSP Autocompletion capability as noted here:

• feat(lsp): completion side effects
• Builtin Autocompletion merged!
• Neovim LspAttach documentation
• MariaSolOs / builtin-compl.lua

Using native capabilities, where possible, seems more in line with the kickstart.nvim philosophy, "A launch point for your personal nvim configuration".

My 2cents.

[rfletchr]

I still believe that the Rust build chain is a complication that kickstart.nvim should avoid. I do note that pre-compiled blink binaries are offered for some platforms & releases. But as a Linux user I once had blink build it's library (via my installed Rust) rather than use the pre-compiled binaries; I don't know why.

An alternate strategy is to avoid nvim-cmp vs blink debates and instead migrate to the upcoming Neovim 0.11 builtin LSP Autocompletion capability as noted here:

• feat(lsp): completion side effects
• Builtin Autocompletion merged!
• Neovim LspAttach documentation
• MariaSolOs / builtin-compl.lua

Using native capabilities, where possible, seems more in line with the kickstart.nvim philosophy, "A launch point for your personal nvim configuration".

My 2cents.

favouring the in-built system seems very sensible.