Feature/snacks picker

[oriori1703]

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

[oriori1703]

Also, I can move the stylua changes to a different PR / remove them entirely

[kaezrr]

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

[kaezrr]

update the libary key of lazydev.nvim in init.lua to the following:

    ...
    library = {
      -- Load luvit types when the `vim.uv` word is found
      { path = '${3rd}/luv/library', words = { 'vim%.uv' } },
      -- Load snacks.nvim when `Snacks` word is found
      { path = 'snacks.nvim', words = { 'Snacks' } },
    },

Otherwise the lua lsp is gonna show a lot of undefined global warnings in your snacks picker configuration. All other changes looks fine.

[oriori1703]

update the libary key of lazydev.nvim in init.lua to the following:

Oops, I forgot to copy it from my config 🤦
I pushed a fix for this now.

I also split the style lua changes to a different PR :D

[kaezrr]

Looks good to merge

[nickgnd]

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 ✌️

[dam9000]

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.

[oriori1703]

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 😄

[Noustaa]

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.

[kaezrr]

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.

[brianhuster]

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

[ro0gr]

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.

[corymhall]

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.

[nickgnd]

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 ✌️

[feoh]

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.

[yetyetanotherusername]

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.

[feoh]

@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?"

[SetsuikiHyoryu]

* 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:

1. 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.

2. From the changes you've made, it doesn't seem to simplify key mapping configuration.

3. 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.

   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.

[feoh]

@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.

[oriori1703]

@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.

[oriori1703]

1. 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.

[oriori1703]

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)

[feoh]

@oriori1703 Good to know, thanks! If more people chime in here and want it merged, I'll merge it!

[szechp]

After reading this thread I realized that there are users who treat this repo as if it were a distro and that's when all trouble starts.

In the README it clearly states:

NOT a Neovim distribution, but instead a starting point for your configuration.

Fork this repo so that you have your own copy that you can modify, then install by cloning the fork to your machine using one of the commands below, depending on your OS.

This repo aims to help you learn how to independently set up your config by going through some popular plugins and giving you nice defaults, giving examples of setting up essential plugins like a picker, algo goes the extra mile by having examples of a separate module with linting, debugging tools.

As a user, after going through the whole document, you should be able to swap any plugin of your preference, add/remove stuff you need/don't need, etc.

This repo is not meant to act your configuration directly, but as quoted above, you should fork it and start customizing your config.

Updates in this repo should only cover essential maintenance, e.g vim API changes, breaking changes in plugins included, etc. A good example of a proper PR is the changes in LSP config on neovim 0.11, or Mason v2.

So, yes the essential plugins included in this repo may change but it shouldn't cause a big discussion here. Some people may prefer nvim-tree instead of neo-tree, others may prefer the mini files, oil, etc. After reading this document you should be able to swap it for any of your preference, same with the picker.

This repo aims to help you save probably hours of documentation reading by explaining what every option does, how to lazy load plugins, what opts={} does, what is an LSP and how to configure it, etc. Everything is documented, not plugin specific, but about the process of setting up your preferences.

If you are depending on kickstart as your distro you probably didn't get the intention of the repo stated in the README. The lockfile is intentionally included in the gitignore file so you exclude it after forking.

Let's help maintain this repo as a kickstart point and learning document of neovim config rather than treating this as a distro :)

Exactly, but since we started to integrate stuff like telescope, there's gonna be some conflicting opinions, and it invites users to use it as a distro instead of a starting point. That's why I propose removing stuff like this, and maybe provide optional configs, or completely do away with those all together. The repo as it is now invites people to use it as a distro. That's why we have a bunch of issues every time something changes, because people fork but use it as a distro.

[gmnz]

I don't think it's a good idea to have a telescope like plugin included but off by default. Out of the box usability is very important for new users. How I understand it is that kickstart is a meta distro, not a distro, cause it does want the user to tinker with it not just install and use it, but it's also not just a documentation or a tutorial, cause it always has been pretty usable out of the box. It should have an effect on the new user like: Wow, this is pretty cool out of the box experience. Let's see if I can change this and that detail and maybe find a plugin that does this or that and add it.

All I'm saying is that someone has to decide which plugins go in and which out, doesn't matter if they're on by default or just included like a disabled extra, the decision has to be made by somebody and if the maintainer finds it difficult to do this on his own because of different opinions of the users, he should find a way to delegate this deciding process to the users to make it easier for him. At least that's one way to make it easier to make a decision. There are other ways. But the point is, somebody has to make the decisions, because the starting point for new users has to be up to date. It can't go on using e.g. telescope when nearly all the rest of the nvim users will be using fzf or snacks, which I don't think is the case yet, there are probably still many users of telescope, but in a year or two that may not be the case anymore.

[szechp]

I don't think it's a good idea to have a telescope like plugin included but off by default. Out of the box usability is very important for new users. How I understand it is that kickstart is a meta distro, not a distro, cause it does want the user to tinker with it not just install and use it, but it's also not just a documentation or a tutorial, cause it always has been pretty usable out of the box. It should have an effect on the new user like: Wow, this is pretty cool out of the box experience. Let's see if I can change this and that detail and maybe find a plugin that does this or that and add it.

All I'm saying is that someone has to decide which plugins go in and which out, doesn't matter if they're on by default or just included like a disabled extra, the decision has to be made by somebody and if the maintainer finds it difficult to do this on his own because of different opinions of the users, he should find a way to delegate this deciding process to the users to make it easier for him. At least that's one way to make it easier to make a decision. There are other ways. But the point is, somebody has to make the decisions, because the starting point for new users has to be up to date. It can't go on using e.g. telescope when nearly all the rest of the nvim users will be using fzf or snacks, which I don't think is the case yet, there are probably still many users of telescope, but in a year or two that may not be the case anymore.

And that’s the root of the problem—thinking of it as a “meta distro.” As the name suggests, it should be a starting point for people on their Neovim journey. In my opinion the focus should be on providing a minimal, clean base with clearly documented, optional plugins that are easy to enable. Power users can extend it however they like with Lua, while others can just pick and use preconfigured tools straight off the shelf.

I’ll open a corresponding merge request sometime next week—we can continue the discussion there.

Or let's go back to that MR:

#473

Having it modular allows us to provide multiple config examples, and we could focus on providing a unified base with multiple options for users to decide on.

[rivenirvana]

I acknowledge the discussions here, but it's starting to feel off-topic, and there is still no identifiable concensus regarding the original purposes of the PR. Should this be moved to its own issue?

[net]

To bring it back to the original PR, for me the issue is:

1. A basic Neovim configuration need a good picker.
2. Telescope is not a good picker (slow, frustrating to customize, doesn't have frequency sorting, less and less maintained, arguably unaesthetic). It had its time when it was the best, but there's a better option now.
3. snacks.picker is the best picker today (and, unlike fzf-lua, doesn't require installing a third-party tool).
4. It is unfortunate that it comes bundled in a package with several other plugins, but those plugins aren't enabled by default so the main cost is just the disk storage.
5. From my perspective, the pragmatic choice to give users a fast, good experience out of the box wins out over the principled—though valid—desire to exclude plugin bundles.

My motivation for advocating for merging this PR is not any effect it would have on my own configuration—I switched to snacks.picker a couple months ago and have no personal need for this to be merged. My motivation is entirely that I want new Neovim users to be set down the path of creating the best possible configuration for themselves, and from my own experience, I don't believe Telescope serves that purpose well.

[ro0gr]

I just disagree with a couple of points, or dont follow it.

but those plugins aren't enabled by default so the main cost is just the disk storage.

For me disc storage does not matter.
However, AFAIU all of plugins, whether enabled or not, contribute to the plugins update logs. This is more annoying to me ux wise.

Telescope is not a good picker (slow, frustrating to customize, doesn't have frequency sorting, less and less maintained, arguably unaesthetic).

I might miss something, but as of now, the latest commit to the snacks happened 4 month ago, while telescope had it's latest commit a month ago, according to their main branches. So this point feels a bit unfair to me.

[rivenirvana]

I'm really wondering if the PR to kickstart-modular is necessary. Personally, I don't think this is the best way to go about this whole thing.

• Firstly, progress has stalled because the main maintainer took a break.
• kickstart-modular is only a downstream variation of what kickstart offers.
• Nor does it aim to cherry-pick upstream PRs for early access or testing.
• Alternative features/options is not the appeal of kickstart. I believe it's better to stick to a specific experience catering to newcomers to the current state of neovim and its ecosystem. Let's not deviate kickstart-modular further from upstream, and just reevaluate reorganize init.lua to a multi file setup #473 to improve swapping out plugins. If plugin discoverability is the problem, let's direct users to rockerBOO/awesome-neovim.

I said this is starting to be off-topic because what actually needs to be addressed first is meta to the repo as a whole.

We need better documentation and guidelines regarding contribution, as well as processes and criteria for things like plugin replacements. Specifically, I'd like to suggest the following:

• Open Discussions in this repo for exactly these situations, to gauge interest and encourage discourse, or to keep watch for shiny plugins. Use Polls for voting.
• Less PRs, please. The "PR first, appeal/discuss later" approach is just maintainer burden, especially in this case. Same for varying implementations (ie feat: add support for new LSP config API in Neovim 0.11+ #1475 and feat: improved lsp setup for nvim > 0.11 #1590 though not related to plugin changes) that fragment discussion. Your personal branch can be referenced without making a PR.
• Be verbose on what criteria kickstart cares about regarding its chosen plugins, these should be forefront when appealing to everyone else for a replacement.
• Document the above (CONTRIBUTING.md? PR template?). I would like to contribute, a "vision", "goals", "philosophy", "principles" document might help #1372 could be where we can elaborate on this.

I believe efforts toward these points are more actionable at the moment, will result in quicker resolving of such issues in the future, and make the repo easier to maintain.

[en9inerd]

Telescope is not a good picker (slow, frustrating to customize, doesn't have frequency sorting, less and less maintained, arguably unaesthetic). It had its time when it was the best, but there's a better option now.

I don’t agree that Telescope is a bad picker. I use it with ripgrep and fd, and I don’t see any real speed issues. Customization has also been straightforward for me—it has a large community and lots of examples.
Snacks.picker might be good too, but bundling a whole plugin pack just to switch pickers feels like overkill, especially when Telescope works well for many users. Let people choose what works for them instead of pushing a full bundle by default.

[net]

I might miss something, but as of now, the latest commit to the snacks happened 4 month ago, while telescope had it's latest commit a month ago, according to their main branches.

I can see why it looks this way. The maintainer of snacks.nvim, @folke, who is also the maintainer of lazy.nvim,which is kickstart's plugin manager, as well as which-key.nvim, lazydev.nvim, tokionight.nvim, and todo-comments.nvim, all of which are used by kickstart, is currently on vacation. If you look at the commit log before he went on vacation you'll see very active history.

I use it with ripgrep and fd, and I don’t see any real speed issues.

I also use rg and fd and had performance issues with Telescope on our large monorepo (M1 Max, 64 GB). On small projects Telescope's performance is fine, but I don't think we should assume that is sufficient for new users.

[guru245]

I prefer Snacks.picker over Telescope, but I'm still using Telescope for lsp_incoming_calls since that feature is missing in Snacks.picker. I made both layouts identical, so it looks like I'm using one picker.

[szechp]

I've been thinking about how to make this optional, so the default config still uses Telescope, but we can optionally replace it. I'm not really sure how best to approach this though, since it's not something we can easily toggle like neo-tree. It overrides some built-in behavior directly.

I asked ChatGPT and it suggested this snippet:

if not vim.tbl_contains(vim.tbl_map(function(s) return s.name end, specs), 'kickstart.plugins.snacks') then
  table.insert(specs, {
    'nvim-telescope/telescope.nvim',
...
  })
end

I haven't tested this yet, mostly because it feels like it goes against what Kickstart is aiming for.

Do you guys have any ideas on how we approach this kind of thing in general? Not just this specific plugin, but more broadly when we want to offer options for something built-in while keeping the default setup clean.

(This all would be so much easier if the decision for having a modular approach in general was made back when it came up)

[guru245]

@szechp
My idea is as follows:

if (telescope)
  require 'kickstart.plugins.telescope',
else if (snacks)
  require 'kickstart.plugins.snacks',
else
  require 'kickstart.plugins.fzf-lua',

Users can select one of them or everything after tweaking the conditions.

[szechp]

Wouldn't we have to specify those variables then somewhere in the config?

🫠 This all doesn't seem very Kickstarter like to me.

I know you probably are tired of me saying this by now, we wouldn't have all this discussions with a modular setup 😅

[guru245]

@szechp We already have a practice. See below.
vim.g.have_nerd_font = true

[rivenirvana]

I do not agree that vim.g.have_nerd_font = true fits this case and sets a precedent. That aggregate of icons has always been developer-oriented, and a lot of people use or depend on it nowadays especially terminal users, devs or not (download stats for releases in the nerd-fonts repo should speak for this). It fits with a kickstart that's aiming to be a sane experience for new users to neovim and expecting some features that have largely become commonplace, easing them into learning and creating their own config.

It should only be about documentation and a simple configuration that keeps up with core neovim. The plugin set is really irrelevant, as long as it reflects the current state of neovim and its plugin ecosystem, as well as what features turn out to be largely beneficial or unanimously accepted in modern software dev. Everything else is deferred to user preference. Providing 2 or more file picker configs is out of scope, it's maintenance burden, and would probably just lead to more PRs wanting to get their plugin-of-the-week in.

I'd agree that it should be easier to switch out plugins if a user wants to, but I'd insist that the solution for this is more proper documentation about how to write your own configs (as well as, again, reconsidering a restructuring effort #473) instead of providing and maintaining multiple configs for same-feature plugins, engineering a framework for managing them and their dependencies, and then making sure any combination of enabled plugins play well with each other.

[glaulher]

I’d like to share a suggestion:

Core init.lua should only include a minimal set of essential plugins (e.g. LSP, Mason, colorscheme, treesitter, basic utils).

Everything else ( git plugins, formatting, etc.) could live in a kickstart/plugins/ folder as optional modules:

Users can enable a module by simply importing it.

Each plugin lives in its own file — so the base config stays clean and lightweight.

We could also have a community/plugins/ folder where third-party or contributed modules live:

Why this could help:

Keeps the core setup minimal and approachable for beginners.

Reduces discussion around preferred plugins — people only load what they want.

The folder community/plugins/ folder could serve as a place for suggested plugin setups and extra integrations:

A great help for people new to Neovim who want to explore common tools.

Contributors could share their own configs there — without bloating the core.

Since Kickstart is not a full distribution but a starter configuration, this distinction reinforces its strength: simplicity and approachability.

[gmnz]

I do not agree that vim.g.have_nerd_font = true fits this case and sets a precedent. That aggregate of icons has always been developer-oriented, and a lot of people use or depend on it nowadays especially for terminal users, devs or not. It fits with a kickstart that's aiming to be a sane experience for new users to neovim and expecting some features that have largely become commonplace, easing them into learning and creating their own config.

It should only be about documentation and a simple configuration that keeps up with core neovim. The plugin set is really irrelevant, as long as it reflects the current state of neovim and its plugin ecosystem, as well as what features turn out to be largely beneficial or unanimously accepted in modern software dev. Everything else is deferred to user preference. Providing 2 or more file picker configs is out of scope, it's maintenance burden, and would probably just lead to more PRs wanting to get their plugin-of-the-week in.

I'd agree that it should be easier to switch out plugins if a user wants to, but I'd insist that the solution for this is more proper documentation about how to write your own configs (as well as, again, reconsidering a restructuring effort #473) instead of providing multiple configs for same-feature plugins, engineering a framework for managing them and their dependencies, and then making sure any combination of enabled plugins play well together.

Exactly, it doesn't make any sense to include alternative same feature plugins in kickstart. If it isn't obvious that there might be other similar plugins, one comment saying "You can install other plugins or even replace plugins that are already included with similar plugins" or something like that would be enough. I mean people who want to use kickstart want to learn (or they're using the wrong "distro"), so they should be ready to google things or ask AI, if a similar plugin to e.g. telescope exists.

If somebody wants a list of quality nvim plugins, there's always this repo:
https://github.com/rockerBOO/awesome-neovim
Why do the same thing when somebody has already done it? Each plugin has installation instructions on its github site and intructions how to configure it. And if somebody doesn't want to learn and only wants to use nvim he can just use LazyVim or AstroVim or whatever.

If somebody really needs kickstart to be more distro like, he should just create a fork and name it kickstart++ or whatever, so it is clear from the name that it is similar to kickstart but has more stuff included.

[szechp]

#1632

i just explicitly set enabled = true for telescope, added some comments to explain and moved the lsp config that requires telescope inside the the config block of telescope.

there is now an entirely optional snacks.lua file, that can be enabled by anyone if they want it. It's in the same folder as neo-tree and other optional plugins. I hope this satisfies every camp, both the purist but also the ones that like to try their new shiny plugins.

[oriori1703]

It's been a while since I last responded to this this 😊 .
After reading a lot of the comments, I find myself mainly agreeing with @rivenirvana and @gmnz:

It should only be about documentation and a simple configuration that keeps up with core neovim. The plugin set is really irrelevant, as long as it reflects the current state of neovim and its plugin ecosystem, as well as what features turn out to be largely beneficial or unanimously accepted in modern software dev. Everything else is deferred to user preference.

Kickstart is aimed at beginners who want to learn and therefore should not have a complicated plugin system that will overwhelm beginners with the choice of which plugins they want, before they even know what half of the plugins do (or even how to use vim).

IMO the best approach is to only have one file picker plugin.
If there is not consensus (which there isn't) I think someone with authority in this repo should just make a choice between the two.
Either choice is fine, and better then confusing beginners with a choice between two very similar plugins (even if I personally think snacks is the better choice).

In the absence of a decision I think @szechp's solution is a good compromise because it is well documented (but a bit worse then just choosing one of the pickers).

[net]

Mostly agreed, although I don't think kickstart should offer a choice. Beginners aren't going to have an opinion on which they prefer.

Also key is @carloscalla's comment:

After reading this thread I realized that there are users who treat this repo as if it were a distro and that's when all trouble starts.
...
This repo is not meant to act your configuration directly, but as quoted above, you should fork it and start customizing your config.
...
So, yes the essential plugins included in this repo may change but it shouldn't cause a big discussion here. Some people may prefer nvim-tree instead of neo-tree, others may prefer the mini files, oil, etc. After reading this document you should be able to swap it for any of your preference, same with the picker.
...
Let's help maintain this repo as a kickstart point and learning document of neovim config rather than treating this as a distro :)

Merging this PR does not force anyone currently using and happy with telescope to switch. Updates to this repo are about what's best for new users, not existing users.

[szechp]

I could split my PR: I think it's essential to get telescope out of the lsp config. Telescope is just too deeply integrated. It should be easy to remove a plugin, without going through the trouble to look for cross plugin dependencies. At least for a picker.

[szechp]

I could split my PR: I think it's essential to get telescope out of the lsp config. Telescope is just too deeply integrated. It should be easy to remove a plugin, without going through the trouble to look for cross plugin dependencies. At least for a picker.

I've gotten around to doing this now:

#1640
and
#1632
are now separate.

[glaulher]

I've been thinking about plugin configurations in kickstart.nvim, and I wanted to suggest the idea of creating a wiki to collect and share how to add and configure plugins, including how to replace existing ones within Kickstart's structure.

This PR actually got me curious, and I ended up migrating to snacks.nvim, even enabling its file explorer. While experimenting, I realized how useful it would be to have a central place with examples and guidance.

Some setups can be quite complex. For example, I spent a long time figuring out how to properly integrate Java development tools, including Spring Boot, debugging, SonarLint, and so on.

I believe a community-maintained wiki could really help others by providing direction and saving time, especially for those trying to extend Kickstart in more advanced ways.

It could also help reduce (or even eliminate) PRs that are primarily about swapping or adding plugins, by offering a clear, shared space for plugin suggestions and configuration examples.

[rivenirvana]

I've been thinking about plugin configurations in kickstart.nvim, and I wanted to suggest the idea of creating a wiki to collect and share how to add and configure plugins, including how to replace existing ones within Kickstart's structure.

This PR actually got me curious, and I ended up migrating to snacks.nvim, even enabling its file explorer. While experimenting, I realized how useful it would be to have a central place with examples and guidance.

Some setups can be quite complex. For example, I spent a long time figuring out how to properly integrate Java development tools, including Spring Boot, debugging, SonarLint, and so on.

I believe a community-maintained wiki could really help others by providing direction and saving time, especially for those trying to extend Kickstart in more advanced ways.

It could also help reduce (or even eliminate) PRs that are primarily about swapping or adding plugins, by offering a clear, shared space for plugin suggestions and configuration examples.

See my previous suggestions above, I think enabling Discussions would be a better fit for this. #1481 (comment)

[szechp]

(comment)

This is how folke does it for most of his plugins. People could just post their configs there.

[glaulher]

I've been thinking about plugin configurations in kickstart.nvim, and I wanted to suggest the idea of creating a wiki to collect and share how to add and configure plugins, including how to replace existing ones within Kickstart's structure.
This PR actually got me curious, and I ended up migrating to snacks.nvim, even enabling its file explorer. While experimenting, I realized how useful it would be to have a central place with examples and guidance.
Some setups can be quite complex. For example, I spent a long time figuring out how to properly integrate Java development tools, including Spring Boot, debugging, SonarLint, and so on.
I believe a community-maintained wiki could really help others by providing direction and saving time, especially for those trying to extend Kickstart in more advanced ways.
It could also help reduce (or even eliminate) PRs that are primarily about swapping or adding plugins, by offering a clear, shared space for plugin suggestions and configuration examples.

See my previous suggestions above, I think enabling Discussions would be a better fit for this. #1481 (comment)

This is really nice! I took a look at how LazyVim handles this, and I think the way they organize things under Discussions is very effective.

In particular, the "Recipes" category there helps a lot, it solves exactly the kind of issues we often see with PRs about adding or replacing plugins. Having a structured forum or discussion space like that could make everything flow much more smoothly and keep the repository clean.