Repository navigation
Command Palette search algorithm needs to prioritize "longest substring" match, may need multiple passes #6693
Description
I have two commands:
- Split Pane, split: horizontal
- Split Pane, split: horizontal, profile: SSH: Antares
If I search for sp anta, I expect 2 to weight higher than 1. I'm getting the opposite, though:
We only run one pass over each command for the whole search term; [SP]lit p[AN]e, spli[T]: horizont[A]l is a complete match; since it's a subset of the Antares version, we never get to the more specific ... profile: SSH:... part.
Reacted by Nicole and WSLUser
Activity
DHowett commentedon Jul 23, 2020
Mike Griese (@zadjii-msft) more modest proposal, and one I'd like to work on for Hackathon (!)
It looks like VSCode has three matchers. The first one to return a result just straight-up wins, and there is no weighting. This is important.
All other matches are sorted strictly alphabetically. This continues to support the case where users memorize commands by their first initial, and doesn't break the case where users might want "p" to match "S[p]lit Pane" for some reason. It'd sort below anything that started with a P because S>P.
I'm guessing that they found users really want a constrained search, not a generic fuzzy search, for their commands. We might be in the same boat because our users will remember key things about the commands (profile name, index, split type, action, etc.).
VSC also returns, as a result of fuzzy match, a list of ranges. If we adopt that, it will make it easier to get the range of text we are supposed to embolden.
zadjii-msft commentedon Jul 23, 2020
Wait but why no weighting?
DHowett commentedon Jul 23, 2020
So, I think that with "first match wins" and running matchers in that order we'll get the vast majority of things users want without having to get into relative ordering discussions like the one that made me file this bug 😄
This is unsubstantiated and, perhaps, unknowable, but I think that most commands are going to be matched by either full-prefix or word-by-word-prefix. There's a higher likelihood that somebody is going to disambiguate an ambiguous match by typing either successive word-start letters or by simply choosing the right one from the very reduced list.
Unfold for a bunch of matching cases. It was longer than I expected.
As an example, take the command names from the OP (plus a couple more)
and the needles
sp anta,spanandspvandspveweights
If we do weighted matching, we get (approximately) the following.
sp antaspanspvit's a toss-up, which is fine - the user may disambiguate later
spvespvaflips them around (which is fine)first-past-the-post
sp antaspanSame as above, actually.
spvuser disambiguates w/
aorespveAnyway, I'm not sure fuzzy plus weighting is better. If we want to render the results to the user we are going to bold a bunch of weird letters or we're going to have to do a runoff search to re-weight the matches and optimize for longer substring runs.
If we're going to do that, and reprioritize longer substring runs, we may want to just ... try to guess at the substrings people are going to use (my theory is that they're the beginnings of their action-words) ... which eventually takes us to "why not just match word prefixes?"
DHowett commentedon Jul 23, 2020
Further discussion: maybe we should do weighting by algorithm -- full prefix is better than wordwise prefix which is further better than contiguous substring.
lhecker commentedon Aug 4, 2020
For reference and further research I'd like to mention the relatively popular project fzf and its algorithm.
Update command palette search to prioritize "longest substring" match. (