Expand description
Filtering and ordering the command list.
A query is split on whitespace and every term has to be found as a
contiguous run of characters. Letting the letters of one term scatter across
a field fills the list with entries that share nothing with what was typed:
git otherwise matches Get-ChildItem through its g, i and t. A query that
nothing contains therefore matches nothing, so every row on screen holds
what was typed.
Match quality is the primary sort key and is deliberately coarse. Fine grained scores reorder neighbouring entries for reasons the user cannot see, and a picker whose order cannot be predicted breaks the muscle memory it exists to serve. Frecency only breaks ties inside a bucket, and the shorter command breaks what frecency cannot, which is every tie on a fresh install.
The buckets, strongest first: every term starting a word or the field, or
not; then the field the weakest term was found in, command before
description before tags; then whether that term opened the field or a word
inside it. The field outranks the position because the command is what the
user is looking at and typing towards. “git st” is spelled out in
git status, and a description that merely begins with “Stage” should not
put git add above it.
Inside the top bucket, a command that begins with the query exactly as
typed comes first. Typing the start of a command is the most direct thing a
user can do, and git commit should not lose to git cherry-pick <commit>
because a placeholder happens to share its name.
Structs§
- Candidate
- An entry with its command already resolved for the active shell.