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!

[feoh]

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

[feoh]

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

[Meliketoaste]

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.

[oriori1703]

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

[oriori1703]

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 #1484 is merged (which I originally used when I opend this PR)

[umutondersu]

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

[net]

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.

[carloscalla]

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.

[1Naim]

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

[szechp]

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

I think so too, I merged this MR to my config, and with this I could replace neo-tree, telescope, and toggleterm. So this makes my config much leaner. With mini and snacks, even though they have some overlap, one can make a very lean but functional ide config. So I'm all for this change.

[ro0gr]

I have a feeling that "Swiss army knife" distributions like mini and snacks might not be the best fit for a project like Kickstart. In my view, Kickstart aims to be as minimal as possible to avoid unnecessary noise.

On the other hand, distributions like mini and snacks provide a lot out of the box, and it’s not always clear where to draw the line when it comes to enabling new features. For example:

replace neo-tree, telescope, and toggleterm

Neo-tree is disabled by default, and toggleterm isn’t even part of the current Kickstart setup. I’m pretty sure there are plenty of other cool features included, but they feel out of scope for a minimal base like Kickstart.

Another reason I’m personally not a fan of "Swiss army knife" packages is that they tend to clutter package manager updates with unrelated logs. In my opinion, if we had something like the snacks picker as a standalone package, that might be a better approach.

[gmnz]

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've read through some of the comments for this pull request, so sorry if I'm repeating something that was already said, but I think @feoh is right about what he has written here. I think the solution would be to create some objective criteria on which plugin to choose if there are multiple plugins offering very similar features. Maybe git stars of the plugin? Might be off sometimes but at least it's objective.

The same goes for plugins with new features, there should be some objective criteria, like e.g. VS Code, the most popular IDE, contains a feature by default, so we should have a plugin for this by default, because VS Code is right now (hopefully not for long) the industry standard. So programmers will probably want lsp, linting, formatting, file manager, auto pairs, git functionality etc. Again, this is not ideal, but it's close to objective criteria. If VS Code has it by default, why shouldn't we? At least as a /kickstart/ file.

Reason I write this is I find all the nvim distros pretty bad and kickstart is the only "distro" that I find usable, because it doesn't force users to use it in some way, it's something like a documentation with good executable examples of code and it isn't managed by one person's decisions only. So it would be really pity if it fell apart because there are no objective criteria on how to manage this repo in the future. So let's set some criteria, let's discuss it, let's vote, let's do something about it. Because if this project stops to work, we'll either have to use some distro or completely own config and search for new plugins and ideas on our own instead of just doing a pull from time to time.

[szechp]

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've read through some of the comments for this pull request, so sorry if I'm repeating something that was already said, but I think @feoh is right about what he has written here. I think the solution would be to create some objective criteria on which plugin to choose if there are multiple plugins offering very similar features. Maybe git stars of the plugin? Might be off sometimes but at least it's objective.

The same goes for plugins with new features, there should be some objective criteria, like e.g. VS Code, the most popular IDE, contains a feature by default, so we should have a plugin for this by default, because VS Code is right now (hopefully not for long) the industry standard. So programmers will probably want lsp, linting, formatting, file manager, auto pairs, git functionality etc. Again, this is not ideal, but it's close to objective criteria. If VS Code has it by default, why shouldn't we? At least as a /kickstart/ file.

Reason I write this is I find all the nvim distros pretty bad and kickstart is the only "distro" that I find usable, because it doesn't force users to use it in some way, it's something like a documentation with good executable examples of code and it isn't managed by one person's decisions only. So it would be really pity if it fell apart because there are no objective criteria on how to manage this repo in the future. So let's set some criteria, let's discuss it, let's vote, let's do something about it. Because if this project stops to work, we'll either have to use some distro or completely own config and search for new plugins and ideas on our own instead of just doing a pull from time to time.

Thanks for the thoughtful comment — I agree this PR really shows how hard it is to make this project work for everyone.

I'd like to propose a radical shift: scale the repo back to a truly minimal kickstart — just LSP, cmp (like blink), Treesitter, and Mason. Then we can provide example config files for popular additions — one with Telescope, one with Snacks, etc. People can pick what they want instead of arguing over defaults.

We don’t need to recreate LazyVim or VS Code. Kickstart should stay minimal, focused, and flexible — a solid starting point, not a full distro.

[gmnz]

I thought about this a little bit more since yesterday and realized that Arch Linux is a similar project and therefore had to solve the same problem probably. Of course, they have some tools of their own, but they are trying to be pretty vanilla with their packages, good documentation is their top priority and they have to decide what packages will be in the official repos and which will be in AUR. How do they do that? This is what the documentation of AUR says:

A good number of new packages that enter the official repositories start in the AUR. In the AUR, users are able to contribute their own package builds (PKGBUILD and related files). The AUR community has the ability to vote for packages in the AUR. If a package becomes popular enough — provided it has a compatible license and good packaging technique — it may be entered into the extra repository.

So the problem would be, how to measure the popularity of plugins in our case. We could just do it the old good democratic way. Let's have a poll once a month or every second month and vote for packages. Let's set some thresholds for plugins on by default and a lower threshold for /kickstart/ optional packages off by default. The rest that doesn't reach the threshold just won't be included.

I know, there's a risk that these "shiny new" guys will overvote the conservative guys, but that might be only temporary. Maybe they would soon leave for some distros beacuse once a month would be just not bleeding edge enough for them and the project would ultimately stay small and conservative. If not, if the "shiny new" guys will stick with kickstart, well, if there's a demand for a kickstart style "distro" that's more bleeding edge, what's the point of going against the will of the users?

This would also simplify the work of the maintainers, because they would just open a poll once a month and wouldn't have to discuss every new plugin separately with the users.

[szechp]

I would propose a different approach, go to a modular config, and just provide a bunch of preconfigured plugins. Wanna have snacks picker instead of telescope? Cool, just make a PR and add, users can decide which one they enable in their config.

[gmnz]

I would propose a different approach, go to a modular config, and just provide a bunch of preconfigured plugins. Wanna have snacks picker instead of telescope? Cool, just make a PR and add, users can decide which one they enable in their config.

How does that make it easier for the maintainer to decide which plugin to include and which not? Every few months he'll get a PR for a plugin that has the same functionality as some, that is already included and the PR author will argue, that his one is newer, better, faster and it should be the default one and the maintainer will have to decide that. I don't see how your proposition would make any difference for the maintainer's problem. Correct me if I'm wrong, maybe I just don't get what you wanted to say.

[szechp]

I would propose a different approach, go to a modular config, and just provide a bunch of preconfigured plugins. Wanna have snacks picker instead of telescope? Cool, just make a PR and add, users can decide which one they enable in their config.

How does that make it easier for the maintainer to decide which plugin to include and which not? Every few months he'll get a PR for a plugin that has the same functionality as some, that is already included and the PR author will argue, that his one is newer, better, faster and it should be the default one and the maintainer will have to decide that. I don't see how your proposition would make any difference for the maintainer's problem. Correct me if I'm wrong, maybe I just don't get what you wanted to say.

There wouldn't be a default plugin—that’s the whole point. The default setup would only include essentials we all agree on, like lspconfig and treesitter. New tools wouldn't replace old ones; they’d just be added alongside, e.g., this MR would add snacks-picker.lua without touching telescope.lua. Users can then choose what to enable in their base config—no debates about what should be "the default." To me this sounds like it would make maintenance much easier this way.

(To be more precise: we should pull out more stuff from init.lua and move them to Lua/kickstart/plugins. Init.Lua should be the barely working minimum, nothing controversial where we all agree on. The user can then pick and choose what to include)

[gmnz]

There wouldn't be a default plugin—that’s the whole point. The default setup would only include essentials we all agree on, like lspconfig and treesitter. New tools wouldn't replace old ones; they’d just be added alongside, e.g., this MR would add snacks-picker.lua without touching telescope.lua. Users can then choose what to enable in their base config—no debates about what should be "the default." To me this sounds like it would make maintenance much easier this way.

Well, but then you have to define some things. What are the essentials? Who is going to decide that? How do you determine if people agree on them or not? That's why I wrote about popularity polling inspired by Arch Linux.

And the problem with including more alternatives will be that plugin devs will submit PRs for their own plugins to promote them even if they may not be that popular and the maintainer will have to merge them all? Or will he have to go back to deciding which to merge and which not? Won't the project become a catalogue of plugins instead of a kickstart then?

I just don't see the solutions for the problem here.

[szechp]

Maybe @feoh can chip in what works best for him.

[carloscalla]

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

[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?