-
Notifications
You must be signed in to change notification settings - Fork 8.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Command Palette search algorithm needs to prioritize "longest substring" match, may need multiple passes #6693
Comments
@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. |
Wait but why no weighting? |
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 weightsIf we do weighted matching, we get (approximately) the following.
|
Further discussion: maybe we should do weighting by algorithm -- full prefix is better than wordwise prefix which is further better than contiguous substring. |
I have two commands:
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.The text was updated successfully, but these errors were encountered: