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.

[feoh]

I'm tempted to close this issue. We all agree that blink is the wrong way to go for the foreseeable future.

[makew0rld]

Works for me. I look forward to maybe seeing builtin LSP usage in the future.

[Saghen]

@feoh Fyi I'm working on making the rust module optional (Saghen/blink.cmp#1316) and 1.0 should come out in the next month or so

[rfletchr]

@feoh Fyi I'm working on making the rust module optional (Saghen/blink.cmp#1316) and 1.0 should come out in the next month or so

legend.

[crochetedbytammysue]

I can’t log into my Facebook profile and page account because I don’t have the login code… Facebook account tammy.bonin96

[crochetedbytammysue]

• @ #Duplicate of Update init.lua #1379

[feoh]

@feoh Fyi I'm working on making the rust module optional (Saghen/blink.cmp#1316) and 1.0 should come out in the next month or so

That's fantastic!

I'm a huge fan of blink and am using it in my own "hand rolled" Neovim configuration :)

The fact that I can put Github Copilot behind an icon in my completion choices and not have it just straight up run my life? PRICELESS!

[Saghen]

Fyi I'm working on making the rust module optional (Saghen/blink.cmp#1316) and 1.0 should come out in the next month or so

1.0 is out and there's an optional pure lua mode via fuzzy.implementation = 'lua'. Would you like to revisit this @feoh? I'd be happy to make the PR for the change

[feoh]

@Saghen Hey that's a VERY kind offer!

I am but a butler, not a decision maker really :)

@rfletchr @makew0rld @bluz71 thoughts?

I have NO skin in this game and am not pushing for this, just asking how people feel since @Saghen was kind enough to offer making the PR.

[makew0rld]

I don't have an opinion on this, the current status is working for me. I yield to community opinion as well.

[PowerUser64]

I think the most valuable thing that blink.cmp offers to the target audience of kickstart is that it validates your config, which helps keep you from getting into the frustrating loop of thinking you're making a change you should see, but you're actually doing it in the wrong place in the config so it does nothing. Also, blink has stellar docs that are highly searchable (and search engine-indexed).

Speaking from my own experience, I have used cmp.nvim for a few years, but I've never felt like I can configure it as well as I can configure blink now. It took me probably 30 minutes to get a decent blink config and a week to get a really solid one, but at all points I felt a lot more confident in my changes and I ended up with a better menu than I ever remember having with cmp, in pretty much every way. Part of this could just be skill issue on my part when it comes to configuring cmp.nvim, but I really think the points I mentioned above made a big difference in my success and I think switching kickstart to use blink.cmp would benefit a lot of people.

Also, I should mention, my current config is based off kickstart as of the start of this year, and I used the kickstart config for cmp.nvim for a month or two before I started with blink.

Thank you Kickstart maintainers for keeping this project strong and reliable! Thank you @Saghen for making such an awesome completion menu!

[bluz71]

@rfletchr @makew0rld @bluz71 thoughts?

An outsider's perspective, I believe kickstart.nvim should not use nvim-cmp nor blink.cmp. Instead I would migrate to Neovim 0.11 native LSP completion solution when it soon becomes available, see the links in my post above. I would also replace LuaSnip with Neovim's native snippets solution.

My feeling is that LazyVim already exists for those that favour an opinionated plugins-first full-featured Neovim distribution (including inbuilt support for blink.cmp).

kickstart.nvim I feel should pare right back to the basics and do the opposite. Ideally kickstart.nvim should feel like helix out-of-the-box, that includes LSP, Snippets and completion. But using Neovim native solutions, if it all possible, to keep it is simple as possible.

I would also switch out tokyonight colorscheme for Neovim's native colorscheme, the new one introduced in Neovim 0.10. A bit plain, but it actually is a nice starter colorscheme, made by the mini.nvim maintainer.

Users would then incentivised to explore their own preferred colorscheme, starting their journey to configure their own personal development environment (PDE in TJ-speak).

Maybe this is all too radical. Food for though nonetheless.

I leave it to this project's maintainers to chose what is best for them, that includes disregarding my previous ramblings.

Best regards.

[cmdrrobin]

If i'm allowed to say something about it, it looks like there are pro's and con's on both sides for using blink.cmp and nvim-cmp. For that reason we could leave it as it is.

To some degree I can agree with what @bluz71 is saying about moving to native Neovim implementations (completion and colorscheme), although we come back to the same question before, when is a good time to use or implement new Neovim features? Should this be an optional feature? (vim.fn.has == 'nvim-0.11')
What version (or versions) should kickstart be supporting?

I'm still using nvim-cmp and feel very happy about it. I don't have a strong opinion about using it nor switching to blink.cmp

[iSolate77]

kickstart.nvim I feel should pare right back to the basics and do the opposite. Ideally kickstart.nvim should feel like helix out-of-the-box, that includes LSP, Snippets and completion. But using Neovim native solutions, if it all possible, to keep it is simple as possible.

I do agree with this 1000%. New comers should have the native experience as much as possible, kickstart.nvim just does the leg work for providing the sane defaults to lower the entry barrier.

Users would then incentivised to explore their own preferred colorscheme

Not only colorcheme but alternative plugins too, which is relevant to this topic.

[cmdrrobin]

Talking about version 0.11, it just got released 😉

[rfletchr]

if nvim-cmp isn't being maintained, and blink no longer requires a compiled component it seems sensible to use blink.

Thinking into the future it would make sense to adopt the new native completions once they mature.

[feoh]

@cmdrrobin @bluz71 @iSolate77 Hey thanks for chiming in everyone.

Are any of you willing to submit the pull requests retooling kickstart.nvim into the lean mean "native" machine you're advocating for?

If you are, great! Provided it doesn't represent a loss in functionality, I'd be willing to merge it.

If not, @Saghen has offered to actually do the work to convert to blink so I'm tempted to go that route.

[cmdrrobin]

Based on my attempt to replace nvim-cmp with natvie vim.lsp.completion, I notice a few things:

• missing documents
• possibility for icons(?)

By the looks of it, you have to go quite advanced to get nvim-cmp replaced with native completion. I'm wondering if this is really the way to go? Or do we want users just basic completion and give them the option for using blink.cmp? (e.g. lua/kickstart/plugins/blink-cmp.lua)

My attempt to replace nvim-cmp with native completion. Maybe i'm totally doing wrong, but this works.

https://github.com/cmdrrobin/kickstart.nvim/tree/compl_native

[feoh]

To be honest, I don't want to fight the consensus because the folks wanting a stripped down "native" experience have a point, but I'm having a hard time understanding in this particular case where going 'native' offers a particular advantage over a plugin.

I really love blink and use it in my own configs. Going with it will allow us to remove some code as-is since we have several places that patch in nvim-cmp which I THINK won't be necessary if we go with blink.

[cmdrrobin]

@feoh agree. If @Saghen still up for it, to create a PR for use of blink.cmp, than that would be nice.

Just a heads-up, maybe use fuzzy = { implementation = 'prefer_rust' } rather than the default fuzzy = { implementation = 'prefer_rust_with_warning' }. With the warning, that can startle (new) users and maybe thinking that they done something wrong.

https://cmp.saghen.dev/configuration/fuzzy.html#rust-vs-lua-implementation

[Saghen]

I was planning to use the lua implementation and add a note for users who would like to use the rust version

[feoh]

I think moving to blink would be a good experience for kickstart users.

@Saghen Please come up with the PR if you're willing. If the native crowd wants to belly up to the bar and submit an alternative we can evaluate both, and if not I'll merge what I have. I don't think we can lose here personally :)

[rfletchr]

I was planning to use the lua implementation and add a note for users who would like to use the rust version

this is the way.

[feoh]

Hi! We now have excellent PRs for both approaches.

I would love it if people would help me figure out which way to go on this, with the understanding that we're all trying to be objective and create the best experience for new users and not necessarily ourselves because we might not be newbies anymore :)

[rfletchr]

Hi! We now have excellent PRs for both approaches.

I would love it if people would help me figure out which way to go on this, with the understanding that we're all trying to be objective and create the best experience for new users and not necessarily ourselves because we might not be newbies anymore :)

personally I'd go with blink. native isn't as feature rich yet and still feels like it needs a bit of wrangling.