-
Notifications
You must be signed in to change notification settings - Fork 11
"Space word jump" heuristic works incorrectly when abbreviation has a space #9
Comments
@dko-slapdash Thanks for the report! I think that setting In general I'd like for command-score to allow aggressive abbreviations so To fix that we'd need to teach the library to notice this kind of leap explicitly, which may be a little more complicated than the change you propose, and I'd be open to trying it out and seeing if the experience is better or worse. FWIW: At superhuman we use this library in a UX that selects one item, and suggests three more out of a list that's a few hundred items long. In that scenario, it's OK for words that don't match anything very well to suggest something because it's better than just showing an error. |
Thanks for the quick reply! We're actually experimenting with SCORE_CHARACTER_JUMP=0, SCORE_TRANSPOSITION=0 mode (because without SCORE_TRANSPOSITION=0, having just SCORE_CHARACTER_JUMP=0 is not enough). Considering that it's unlikely that people would search by mid-word characters (and also since our strings are 3-4 word sentences, not like CamelCaseIdentifiers or file_names.ts. We also don't limit the number of matched strings, i.e. we use superhumanCommandScore as both filtering AND ranking tool. |
If you only want to support matches that are prefix matches of words, then you can likely save a lot of computation time by reducing the number of matches considered. Right now we do |
I think \s approach won’t work, because I want “sefi” (or “se fi” after the change I posted above) to match “search files”. I.e. here “e” matches a mid-word character, but it’s okay, because it goes after “s” which matches a start-word character; same is with “i” after “f”. |
I'm trying to set SCORE_CHARACTER_JUMP=0 to disable matching mid-word characters.
This is to e.g. not let “Fil
te
r by: As
signedT
o” string to match "test" abbreviation which makes sense.Like "words prefix-only search".
But it has some side effect in how the library processes spaces.
Imagine for simplicity that we have
string="se f"
andabbreviation="s f"
In this case, we expect that the abbreviation will perfectly match the string, but it doesn't happen - the score returned is 0.
I think the solution is following:
I.e. if the currently checked abbreviation character is a space, and there is a space in the string, we should continue no matter how far this space is (not necessarily if the current string character is also a space).
The text was updated successfully, but these errors were encountered: