Fetch results from multiple LSPs

[enriclluelles]

Description

Please include a summary of the change and which issue is fixed. Please also
include relevant motivation and context

Fixes #2342

Right now, when you have two LSPs connected to one buffer and you want to, let's say, go to a definition, there's a race condition / non-deterministic behavior in which Telescope uses the answer of the first LSP that responds

As an example (and the actual reason for me submitting this change), if you have a ruby application that uses sorbet, and you're running the Sorbet LSP and RubyLSP for the same buffer (which is pretty useful), what you'll see for telescope.builtin.lsp_definitions will be:

The first two times, it used the locations from RubyLSP, and the third one from Sorbet

With this change applied, this is what happens:

You've got all the results from both LSPs consistently

This leaves us with the issue of what happens if both LSPs returning overlapping locations, so deduplication could be in order
But since this isn't my case and I suspect not a lot of people use multiple LSPs that return the same stuff, I prefer to get your feedback first and maybe implement it later

Also, we should probably remove the list_or_jump implementation since this makes it obsolete I think, but again, I prefer to get feedback first

Apologies if the code is not up to standard, I'm a complete Lua illiterate

Type of change

• New feature (non-breaking change which adds functionality)

How Has This Been Tested?

Manually, as my knowledge of lua is very limited and mostly learned by tinkering with neovim plugins and config

Configuration:

• Neovim version (nvim --version): v0.10.0
• Operating system and version: macOS 14.5 build 23F79

Checklist:

• My code follows the style guidelines of this project (stylua)
• I have performed a self-review of my own code
• I have commented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation (lua annotations)

[jamestrew]

Is there a reason to have a new function called list_or_jump_all as opposed to just altering list_or_jump if the latter is no longer used?

[enriclluelles]

Is there a reason to have a new function called list_or_jump_all as opposed to just altering list_or_jump if the latter is no longer used?

No, I guess I didn't realize it wasn't used anymore, renaming it to leave only list_or_jump

[enriclluelles]

@jamestrew any chance you can run the CI workflows? I think there's nothing left for me to do

[enriclluelles]

@jamestrew done

[jamestrew]

thanks!