nvim-lua
Feature/snacks picker
Switch from telescope to snacks.nvim.
Benefits of snacks compiled from the comments:
- It has more pickers out of the box
- it supports frequency sorting
- it is faster (according to some people, but I don't feel the difference personally)
- it is better maintained
- it is integrated with a lot of other plugins (but so is telescope)
- it is as easy to configure as telescope
- it might make the transition to rolling your own config using kickstart, if you are coming from an nvim distribution that already uses snacks (which I believe all the big ones do)
- and ... it also a bit nicer (but that is subjective)
I just switched my config to use snacks instead of telescope, so I'm opening a PR in case it interests anyone else.
I know that this might be controversial because both Kickstart and telescope were create by teej (which did an awesome job on both BTW), so feel free to close this if you feel it doesn't suite the project.
Also, if you want, we can also easily use snacks.explorer and snacks.indent to replace neo-tree and indent-blanklines
Also, I can move the stylua changes to a different PR / remove them entirely
Damn I was thinking of switching to snacks picker just yesterday, and this PR saves me a lot of time. Also I would suggest to move the stylua changes to a different pr or remove them (just as you suggested), it kind of pollutes this already change-heavy PR.
Cheers
update the
libarykey oflazydev.nvimin init.lua to the following:
Oops, I forgot to copy it from my config :facepalm: I pushed a fix for this now.
I also split the style lua changes to a different PR :D
Hey 👋 i'm pretty new to the neovim ecosystem, so please be patient with me 😅
I have a couple of questions. Is there any difference between telescope and snacks.picker or are they fully swappable? And why snacks.picker should be preferable to the telescope for newcomers (target of kickstart.nvim)?
Thank you for your time, cheers ✌️
Well, I would also like to know why is this necessary, what are the benefits of swapping telescope with snacks picker? One downside is that existing kickstart users who are already accustomed to using telescope and might have already done some minor telescope customisations will need to adapt if this is merged. So I would think there would need to be some substantial improvement or benefit for switching.
On the other hand it is useful to have a branch like this so it is easily to try out some new stuff for those that are interested.
Is there any difference between telescope and snacks.picker or are they fully swappable?
They both offer similar functionality and pickers.
And why snacks.picker should be preferable to the telescope for newcomers (target of kickstart.nvim)?
To be honest, I'm not sure it is preferable. I switched to it mainly because I heard good things, and I was curious about it,
The main advantages I can think of about snacks are:
- It is a suite of plugins, so if another part of the plugin is useful for you it would be easy to enable it.
- It looks a bit nicer?
- This is totally subjective though.
- It might be faster?
- At least that's what I have heard, but I can't really tell the difference.
- It might be more maintained?
- It seems to have a higher frequency of commits, and PR merging. Though folke (the maintainer) is on vacation so it slowed down a bit in the last month and a half.
On the other hand it is useful to have a branch like this so it is easily to try out some new stuff for those that are interested.
This was my motivation behind this PR :smile:
One of the main reason i prefer snacks picker over telescope is that it supports frecency sorting out of the box. It can be added to telescope as well by adding nvim-telescope/telescope-frecency.nvim.
Call me biased but snacks-picker is created and maintained by folke (probably the biggest neovim plugins author), and integrates much nicely with a lot of his other plugins. (Which there are a lot of)
Kickstart aims to ease people into the neovim ecosystem and imo using something like snacks.picker just helps in that direction.
One downside is that existing kickstart users who are already accustomed to using telescope and might have already done some minor telescope customisations will need to adapt if this is merged.
I thought the point of kickstart is that users should copy it to their config and then maintain that config themselves, right? So why would a change in upstream kickstart.nvim affect users config? As I understand, Kickstart is not a plugin, not a distro either, so users don't need to update Kickstart like they update a plugin or distro
So why would a change in upstream kickstart.nvim affect users config?
There are reasonable changes over time that I want to stay in sync with, so I regularly pull this repo to catch up. IDK if that the best approach, but it works fine until we start replacing plugins. For me, there should be a good reason(other than popularity) to replace a plugin.
Note, I'm not saying there is no good reason for the change. I just prefer to have such reasons to be listed explicitly.
Kickstart is not a plugin, not a distro either, so users don't need to update Kickstart like they update a plugin or distro
100% agree with this. Just my two cents, but I think kickstart should represent "how to configure neovim if you started today". Things are constantly changing in the neovim ecosystem as new neovim versions are released, popular plugins stop being maintained, new plugins are created, etc. I've used neovim for years and I would always have a couple of people with neovim config repos that I would follow to try and get a sense of what a good setup was. Now I mostly use kickstart for that, a reference point to update my configuration.
For me, there should be a good reason(other than popularity) to replace a plugin.
I'm not sure there needs to be a objective reason to replace a plugin. Neovim configuration is all a little subjective and I think it should just be based on what the kickstart maintainers view as the "best" (subjective) starting point. I personally use both snacks and telescope because snacks solved performance issues I was having with telescope, but there are some telescope integrations that don't exist in snacks yet.
Thank you all for the kind responses, i really appreciated all the different perspectives ❤️
As newbie, I have to say that i personally find snacks.picker more complete than telescope.
Simple example that made my day: Search File -> insert path/to/file.txt:12 , it opens the file to the selected line, while with telescope I needed to delete the row number (maybe it is possible to handle that with telescope too, but not out of the box).
Cheers ✌️
It's unclear to me whether most people would be in favor of this change.
Thanks for the PR though! If I see a groundswell of support I'll merge.
Just my 2 cents, I tried snacks picker and am going to stick with it. The git log search picker alone has sold me on it.
@yetyetanotherusername The question is not - "is this shiny and tasty and a thing I want".
The question is "Is this something EVERY SINGLE NEW Neovim user MUST start with in order to have a good experience?"
* The following content was translated from Chinese to English by AI. If there is any ambiguity or misinterpretation, please let me know.
Could you record a short video and post it here to demonstrate how snacks.nvim works?
Based on the textual description and the repository README, I personally disagree with replacing telescope with snacks.nvim. Here are my reasons:
-
If it is a suite of plugins, then it violates the principle of single responsibility for components. I understand that it's possible to disable unwanted features, but having to configure all these "extra" options feels confusing to me. Also, I'm not sure whether the related modules are still downloaded to my computer even if I don't enable them. In my opinion, that pollutes my system storage.
-
From the changes you've made, it doesn't seem to simplify key mapping configuration.
-
AI tells me that the main purpose of
snacks.nvimis UI enhancement. In my experience, visual fanciness is often proportional to heaviness. It's like comparing a JK pleated skirt to a noblewoman's gown — the latter is more ornate but cumbersome.Back when I was learning Java, my teacher only mentioned IntelliJ IDEA. Later at work, some colleagues told me about VSCode, and I switched to it because I found IntelliJ IDEA to be quite heavy, as it comes with a lot of built-in features I never used.
Then, when I discovered Vim, I immediately switched from VSCode to Vim/Neovim, because VSCode’s pursuit of a “nice” UI made it impossible to function as a command-line tool. I do like a good-looking interface — but only if it doesn't compromise performance or simplicity. I cannot accept writing code in a browser.
@SetsuikiHyoryu I've been a bit frustrated by the lack of screenshots/video or even any real exhaustive description on the Snack website as well.
@SetsuikiHyoryu I've been a bit frustrated by the lack of screenshots/video or even any real exhaustive description on the Snack website as well.
You can find some screenshots in the dedicated README for snacks.picker.
Though I do agree it's still missing more screenshot and videos.
- If it is a suite of plugins, then it violates the principle of single responsibility for components.
I do agree that it would have been nicer if it was split into multiple plugins, I don't think it's a blocker for kickstart. If it was, mini should also be replaced by something more minimal.
I understand that it's possible to disable unwanted features, but having to configure all these "extra" options feels confusing to me.
You don't have to configure anything to disable the other modules. They are all disabled by default, and need to be explicitly enabled in order to run.
Also, I'm not sure whether the related modules are still downloaded to my computer even if I don't enable them. In my opinion, that pollutes my system storage.
In my opinion, the storage space difference is negligible.
AI tells me that the main purpose of snacks.nvim is UI enhancement. In my experience, visual fanciness is often proportional to heaviness. It's like comparing a JK pleated skirt to a noblewoman's gown — the latter is more ornate but cumbersome.
As discussed in by other people in this thread, there are more benefits to snacks.nvim then visual flare.
- It has more pickers out of the box
- it supports frequency sorting
- it is faster (according to some people, but I don't feel the difference personally)
- it is better maintained
- it is integrated with a lot of other plugins (but so is telescope)
- it is as easy to configure as telescope
- it might make the transition to rolling your own config using kickstart, if you are coming from an nvim distribution that already uses snacks (which I believe all the big ones do)
- and ... it also a bit nicer (but that is subjective)
@oriori1703 Good to know, thanks! If more people chime in here and want it merged, I'll merge it!
it is better maintained
I agree with this. When last I looked, Telescope was rather moribund.
I just need a few more people to chime in saying they want this and I'll merge.
I realize screaming avoidance isn't a great way to run a project, but there we have it :)
Taking another break from rying to maintain this repo :)
There's NO ill will here on anyone's part, but this PR is an excellent example of why trying to run this project is SUPER hard.
<existing users, rightly, ask WHY DO WE NEED BRIGHT SHINY?>
<PR author says - SHINY!>
Chaos ensues :)
I'm opposed to be using snacks personally. I'm personally using fzf-lua but I've used snacks. But I don't really see much benefit over Telescope.
The idea that the "big neovim distribution uses it" Is not really true to my knowledge. Lazyvim recently swapped to fzf-lua, though it has options for both Telescope and Snacks pickers. NvChad uses Telescope and astro uses snacks.
It might "technically" be an marginal improvement. Telescope is far more integrated in plugins. I just don't see substantial benefit. Telescope is better documented as of now. And the way telescope is configured right now just showcases more aspects of configuration.
On another note. If you do add it doing it like this:
config = function()
vim.keymap.set('n', '<leader>sf', snacks.find, { desc = "[S]earch [F]iles" })
It is just more compact. Since rn you are adding more code than removing in the commit.
Lazyvim recently swapped to fzf-lua.
If I understand correctly, according to this reddit post, Lazyvim switched again, and uses snack.picker by default for new installtions (for new installs it stills uses fzf-lua until the user opts in).
On another note. If you do add it doing it like this:
config = function() vim.keymap.set('n', '<leader>sf', snacks.find, { desc = "[S]earch [F]iles" })It is just more compact. Since rn you are adding more code than removing in the commit.
I followed the examples in the from the README for the keybinds. Does doing it this way have any effects on lazy loading?
Also this could also be more compact if https://github.com/nvim-lua/kickstart.nvim/pull/1484 is merged (which I originally used when I opend this PR)
100% agree with this. Just my two cents, but I think kickstart should represent "how to configure neovim if you started today".
My opinion exactly.
I would also be in favor of swapping to snacks.nvim IMO snacks has a better and a more customizable UI/UX, out of box frecency, and better speed.
If it is a suite of plugins, then it violates the principle of single responsibility for components. I understand that it's possible to disable unwanted features, but having to configure all these "extra" options feels confusing to me
Since all 'Snacks' or sub-plugins are opt-in rather than opt-out I think this wouldn't cause an issue
I'm another a longtime kickstart user who moved from Telescope to snacks.picker. Telescope has a lot of issues (only one of which is performance) that snacks.picker does not. I strongly recommend removing Telescope from kickstart—it's caused me a lot of frustration.
If there is going to be a change of the picker I would strongly suggest considering fzf-lua first. This plugin is very well maintained, it has nice defaults (important as it aligns with kickstart philosophy for minimal setup for new users) but it is also incredibly customizable and has superb performance as it uses fzf. Not only that, but also fzf is a tool that many users already use in their terminal even if they are new to neovim, so starting with fzf-lua is a seamless transition.
LazyVim migrated to fzf-lua, then went for snacks, obviously because for folke it would be easier to maintain LazyVim if he is maintaining his own picker and can make everything work better together as a distro if he has control over the plugins as well, but that doesn't mean fzf-lua is worst than snacks in any way.
Personally, I migrated to fzf-lua long time ago when I had problems with my Telescope crashing on repositories with big files and I've been using it ever since. I also tried the snacks picker out of curiosity but I just find fzf-lua more robust.
One more thing, fzf-lua has some pre-defined profiles you can use and one of them is the telescope profile where, as it's documented, they try their best to get the closest match to telescope defaults in look and feel and keybinds. This is also important if kickstart offers a smooth migration from Telescope to fzf-lua optionally.
One more thing, fzf-lua has some pre-defined profiles you can use and one of them is the telescope profile where, as it's documented, they try their best to get the closest match to telescope defaults in look and feel and keybinds
snacks.picker has that too under layout.preset, i.e.
picker = {
layout = { preset = "telescope" },
}
and since I'm commenting here already, I might as well chime in too.
The question is "Is this something EVERY SINGLE NEW Neovim user MUST start with in order to have a good experience?"
If we're strictly speaking about functionality, I don't think there's much if any difference regarding telescope vs snacks.picker. Sure snacks has more features OOTB, but telescope can be extended to match those features by adding more plugins.
I believe what's valuable here is that, in addition to picker, snacks comes with a lot more modules that could potentially replace existing plugins in kickstart. One example is replacing indent-blankline under kickstart.plugins with snacks.indent. Another is snacks.notifier that adds eyecandy to vim.notify and can replace fidget.nvim for LSP notifications/progress
