Telescope PR merged and I have previews again

[dimitarvp]

(NOT MY WORK)

After this NeoVim Telescope PR got merged -- nvim-telescope/telescope.nvim#2395 -- I have put the following in my config.lua:

lvim.builtin.which_key.mappings["f"] = {
  require("lvim.core.telescope.custom-finders").find_project_files,
  "Project files"
}

lvim.builtin.which_key.mappings.b.f = {
  "<cmd>Telescope buffers<cr>",
  "Buffers"
}

...and both project files and buffer switcher now show me previews.

Shout out to @LostNeophyte for engaging with me on Reddit, and here's a pointer to my final comment there: https://www.reddit.com/r/lunarvim/comments/1014usu/recent_update_changed_previewers/j96a0a5/

If there's a better way, let me know (still a VIM noob). If not, feel free to ignore, I just wanted to bring visibility to the Telescope team (and @Conni2461 in particular!) that fixed an issue that was a productivity breaker for me. And now LunarVim benefits from that as well! Awesome job from everyone involved in both communities. ❤️

[LostNeophyte]

the code you have in your config it the current(on master) correct way to enable previews

it should work even before that telescope pr

[dimitarvp]

You told me that but it didn't, sadly.

I tried calling :Telescope buffers and that errored out. The PR fixed it and after that it started working.

Though thinking of it maybe I have to check all GIT repos inside LunarVim, maybe one of them refused to update. (Though I'd expect LvimUpdate to do something like git reset --hard HEAD before doing git pull.)

[dimitarvp]

If we want to follow semantic versioning, Neovim isn't at 1.0 yet. Maybe you can plan such breaking changes for then?

Personally I'd always vote for strong typing. I love dynamic languages and they made me loads of money but there comes one point after which it's a hassle when stuff is so... free and wild, let's call it.

Though as a guy who had to maintain a lot of old software I believe your users -- myself included -- will be most receptive to breaking changes if Neovim itself runs a migration script to change the old configs to the new ones (if such a thing is even possible; I suspect it's not).

[Conni2461]

Uff migration script will never happen. That would require us to write inside your lua config files. Thr best we can do, and we've done that in the past, is offer a migration guide once we realize that your config is out of date.

We, telescope, is also still on 0.1 for this reason. We dont guarantee anything. We released version 0.1.0 and have a stable release branch 0.1.x because we want user away from master, which is sadly the default for all plugin managers. So we can finally expermient again on master, which is currently basically impossible because every experiment, will be instantly roll out to the majority of users and i hate it. Luarocks could also solve this issue because it installs the latest stable version not master but packer.nvim is the only plugin manager with support for that anf with the move to lazy.nvim i dont see that happening.

I am happy that lunarvim adopted to using 0.1.x :) but i am sure a lot of ppl are still running current master

[dimitarvp]

Well okay then. I'd love it if at least Telescope can show a warning akin to "your config seems out of date, please visit this website to migrate"? That can help.

[Conni2461]

we did show a error that points to :help telescope.changelog but yaeh

[LostNeophyte]

I think we did quite well with the telescope config structure with the defaults and pickers table. But i have to admit, its a huge issue that we have preview and previewer that do different things and accept different values. Its also an ossue that there are a tone of internal opts that can be overriden (like previewer and sorter, ...) and those arnt even documented. So yeah a couple of bad decisions are a huge issue and can't be addressed without breaking changes. And every time i do a documented breaking change i have to deal with 20 issues over the next couple of months ....

The config is good when you learn what's what, but it took me a long time to learn it (compared to most plugins), doc/telescope.txt is very long and there are a lot of options. telescope is just extremely configurable, it's overwhelming. the part that took me the longest is is theme in config.pickers table (like here) it took me the most time and I can't find any documentation for it, I probably should have opened a discussion on the repo to ask about it. this part of the docs only shows options for defaults and doesn't link to anything regarding pickers or the explanation is too short for me, it doesn't explicitly say what are the allowed keys, it could say they are the same exact keys from builtin.<picker_name>({opts}), but that doesn't seem to be the case as i don't see theme there. If that part of the docs explained it I think I wouldn't have any problem with the config

I can relate to the documented breaking changes thing, even if you pin an issue with a solution and the error/warning links to it people will still open issues

apart from that one thing I love the plugin, please don't take my criticism harshly and thank you very much for working on telescope ❤️

[Conni2461]

doc/telescope.txt is very long and there are a lot of options. telescope is just extremely configurable, it's overwhelming

i agree, the problem, imo is that telescope is too big. so we end up with a huge documentation that doesnt even include everything

the part that took me the longest is is theme

yep theme was a good idea with a bad architecture. the problem is that theme is a high level wrapper around layout_config with is just a lower level config for layout_strategy which are also just recipes on how windows should be drawn. Resulting in multiple ways of configuring the same thing.

If that part of the docs explained it I think I wouldn't have any problem with the config

yep fair enough. PR welcome :)