Combining sources/pickers

[wbthomason]

Per discussion on Gitter, it would be cool if telescope supported an easy way to combine sources/pickers and merge the results in a common display for filtering.

e.g. doing something like my_combo_picker = my_first_picker + my_second_picker, then my_combo_picker() displays everything from both my_first_picker and my_second_picker.

[cjquines]

currently working on this on cjquines@2a5f69b693d6d0ce63237c152b476660a74e86c3 . exactly how are pickers supposed to be combined? there seems to be a clear way to combine finders by just running both finder commands (see the commit i'm working on), but how will e.g. actions be combined?

i guess one way could be to take each individual item, wrap them with the picker they came from, then make actions to that item call that picker's action or something. but iirc telescope supports actions on multiple items at once, so that doesn't seem to make sense to me.

the option that would be simplest would be to just, when combining two or more pickers, just use the first picker for everything, and only combine the finders. idk if this is good enough though

[fdschmidt93]

I haven't had a look at your branch, but some thoughts off of the top of my head:

• Combining finders (and their entry makers) would be the way to go imo
• I'm not sure we should/could support combining pickers per se. Implementation-wise it's the wrong level to merge varying sources: (a) varying mappings, (b) lots of glue required to resolve logic (multi selections, etc.)
• My primary concern would be varying previewers; previewing would now have to be tied to an entry, which makes sense I suppose. It's more a practical matter that all entries have the same previewer

I would assume the practical conclusion is to enable some sort of finders of finder interface (similar to how filtering probably is will end up being combining multiple sorters) and combining finders will in most cases be more of a user-specific case. I could envision some refactoring to cleanly carve out providers (ie the picker-specific finders) to facilitate customization in user land. It's what appears to be the most maintainable solution while enabling maximum customization. Nevertheless, it's somewhat opinionated.

I hope that makes sense, let me know in case you have more questions.

Other maintainers are very happy to chime in :)

[Zane-]

there seems to be a clear way to combine finders by just running both finder commands (see the commit i'm working on), but how will e.g. actions be combined?

I would really like to see this feature (just combining multiple results from finders.new_oneshot_job for different commands). Any updates / is this possible now?

[Conni2461]

No updates. Planed for after 0.1 release

[luxus]

after bringing up this topic on reddit.
https://www.reddit.com/r/neovim/comments/zr7tj4/turn_telescope_into_an_omnisearch/
maybe now could be the time to add this feature?

[cshuaimin]

+1 for this, combining specific and quick pickers with more general and slow pickers is extremely useful. For example my dream buffer switcher is :Telescope buffers,oldfiles,find_files (if I can combine pickers with comma). I can switch to open buffers / recent files quickly, and fall back to project wide file searching. And I hope that the slow picker is only run when there's few candidates from quick pickers, so slow pickers won't make fast paths slow.

Emacs package consult shows open buffers and recent files together. I hope something exists in Neovim world too.

[lucc]

I have written a small "cycle" picker that can cycle through some pickers and keep the query intact because I was missing this picker combinator described here (and also because it is a feature I know from ctrl-space.vim).

It is not so much a picker combinator (it does not produce a new picker with the combined items) but rather a wrapper to switch between some pickers and take the current query with you.

With some config like this:

local my_cycle_picker = cycle(picker_A, picker_B, picker_C)
require 'telescope'.setup {
  defaults = { mappings = { i = { ["<C-Space>"] = function() my_cycle_picker.next() end } } }
}
vim.keymap.set({"n", "i"}, "<C-Space>", function() my_cycle_picker() end, opts)

on the first press of Ctrl-Space picker_A opens, and on each press of Ctrl-Space the current picker cycles through picker_A, picker_B, picker_C, always takeing the current query with it to the next picker.

Definition:
https://github.com/lucc/vim-config/blob/4c018d5ec2f86e65668ad33aa6f746310d3d9137/lua/telescope/cycle.lua

real world usage:
https://github.com/lucc/vim-config/blob/4c018d5ec2f86e65668ad33aa6f746310d3d9137/lua/plugins/select.lua#L79-L123

If you are interested I could polish this into a PR.

[ghostbuster91]

I think that right now the biggest use case for that would be combining information from multiple language servers.

Imagine a project where you have at least two languages. Both language servers implement lsp_dynamic_workspace_symbols. Without that feature there is no way to present information from both clients.