(mini.pick) Possible to improve/alter lsp.workspace_symbols_live sorting

[stryan]

Contributing guidelines

• I have read CODE_OF_CONDUCT.md

Module(s)

mini.extra, mini.pick

Question

Question: Is there a way to adjust how mini.pick sorts/filters the workspace_symbol_live results to prefer filtering on the symbol names themselves rather than including the filename? Essentially, I want behaviour similar to what fzf-lua has for just this picker.

Context:
I've been trying out mini.pick more and while most of the time it's been fast and great, the lsp.workspace_symbols_live picker has been rather finicky for me. I am working in a a large-ish Go codebase a lot and rely on searching workspace symbols to get around, especially if I don't remember the full function signature I'm looking for.

I have been having trouble getting the live workspace symbols picker to sort or filter in a useful way because it doesn't do any sort of scoring for in-module symbols versus overall workspace symbols, and it seems to filter off filename too rather than just symbol name.

As a rough example (since I can't post real screenshots due to it being a work codebase), lets say I'm looking for a method CreateFoo. I don't remember the exact struct it's on so I try searching for just CreateFoo. With mini.pick the top three results are

1. foo_handler_test.go: MockStruct.CreateFoo
2. foo_handler_test.go: MockStruct.CreateFooModification
3. client.go: WebClient.CreateFoo

Of those options, only the 3rd is somewhat relevant. It gets worse when I remember that oh it's on a service struct and I type in service.CreateFoo. Now my top results are

1. .cache/go/mod/github/bar/service/api.go: CreateLaunchTemplate
2. .cache/go/mod/github/bar/service/api.go: CreateLaunchTemplateV2
3. .cache/go/mod/github/bar/service/api.go: CreateLaunchTemplate
4. and so on. I'm actually not even sure what it's finding fully as the filenames are too long for the picker to show.

For comparison, the same searches with fzf-lua return the following

CreateFoo

1. service/main.go: createFoo
2. tests.go: createCoolFoo
3. tests.go: createTestFoo

service.CreateFoo

1. cool/service.go: service.CreateFoo
2. other/service.go: service.CreateFoo
3. other/test.go: service.createBarFromFoo

Which are all much more relevant to my search.

I'm assuming I'm either holding the picker wrong or I'm expecting too much out of it (since I know most mini.pick pickers do limited sorting since you're fuzzy finding anyway) so if anyone has any tips on how to get better results from it I'd be much obliged! I've been really enjoying all the other pickers and the simple design for custom pickers is great, but unfortunately this is a pretty big part of my workflow so I'd need to either do my LSP symbol lookups through another plugin or go back to fzf-lua for this.

[echasnovski]

I'm assuming I'm either holding the picker wrong or I'm expecting too much out of it (since I know most mini.pick pickers do limited sorting since you're fuzzy finding anyway) so if anyone has any tips on how to get better results from it I'd be much obliged!

The way workspace_symbol_live works is that it delegates the search to the LSP server on every query update. As the used workspace/symbol method supports "a query string to filter symbols by".

It is essentially done by calling Neovim's vim.lsp.buf.workspace_symbol() with current query. This approach, I am afraid, won't change for "managing complexity" reasons.

To double check that everything is okay, could you please compare how :Pick lsp scope='workspace_symbol_live' + typing CreateFoo and :lua vim.lsp.buf.workspace_symbol('CreateFoo') behave? They should show the same set of results, but the first one inside the picker, while the second one inside quickfix list.

---

I am not quite sure how fzf-lua handles things differently here. Quick scan over the repo didn't add information (the implementation is somewhat convoluted due to needing to pass things into fzf process).

The (somewhat documented) solution that I can suggest with 'mini.pick' is to refine matches if you feel there are a lot of false positives. Press <C-Space> once you feel there are enough matches and filter them out with a different query.

[stryan]

Understandable about not changing the approach, that's roughly what I expected the picker to be doing.

To double check that everything is okay, could you please compare how :Pick lsp scope='workspace_symbol_live' + typing CreateFoo and :lua vim.lsp.buf.workspace_symbol('CreateFoo') behave? They should show the same set of results, but the first one inside the picker, while the second one inside quickfix list.

Interestingly, I do not get the same results. mini.pick is returning some different order while both vim.lsp.buf.workspace.symbol() and fzf-lua return the same. I can recreate the problem with one of my public repos if you want to look yourself, but here's what I get:

Here's :Pick lsp scope='workspace_symbol_live' and typing Action:

Here's vim.lsp.buff.workspace_symbol('Action'):

And here's fzf-lua:

So it's just mini.pick that's responding differently. Which is odd, as I don't think i'm configuring it very much. Mini.pick config:

later(function()
	local win_config = function()
		local height = math.floor(0.618 * vim.o.lines)
		local width = math.floor(0.618 * vim.o.columns)
		return {
			anchor = "NW",
			row = 1,
			col = 1,
			width = width,
			height = height,
		}
	end
	local picker = require("mini.pick")
	picker.setup({
		window = {
			config = win_config(),
		},
	})
end)

If needed, I'm using nvim-lspconfig for my gopls configuration, so that's over here

The (somewhat documented) solution that I can suggest with 'mini.pick' is to refine matches if you feel there are a lot of false positives. Press once you feel there are enough matches and filter them out with a different query.

Refining helps! I'll play around with that more too.

[echasnovski]

Hmm... I can reproduce. I'll take a closer look.

[echasnovski]

Ah, the :Pick lsp has custom sorting logic. It was probably added because "later fuzzy matching reorders according to its own rules". But at least for workspace_symbol_live preserving own order might indeed make more sense. I'll look into it.

[echasnovski]

This should now be resolved on the latest main. Along with (what feels like) an improved highlighting for workspace_symbol and workspace_symbol_live scopes.

Thanks again for pointing out this behavior!

[stryan]

I can verify that it's working as expected now and the highlighting is indeed better :) Thanks for the quick fix!