You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is there an existing issue or pull request for this?
I have searched the existing issues and pull requests. I found this: Free word order and parts of words #41 but it does not seem to solve my specific problem
Feature description
I'm a bit frustrated by the fact that the searched term metric matches the term cluster, because of the letters ter which yes, are in the metric word, but not in the original order.
Do you guys confirm? Am I the only one frustrated by this behavior?
Thank you
Desired solution
I'd like Fuse to always respect the order of the letters in the searched term. For my specific example, the searched word metric should not return as a match the word cluster.
Alternatives considered
According to the mentioned thread, a different library (not sure I can mention here, but it's in the link) would solve the problem. I found this thread that seems to discuss a similar topic, but with no actual solution to my specific problem: #41
Additional context
No response
The text was updated successfully, but these errors were encountered:
Is there an existing issue or pull request for this?
Feature description
I'm a bit frustrated by the fact that the searched term
metric
matches the termcluster
, because of the letterster
which yes, are in themetric
word, but not in the original order.According to this SO thread, https://stackoverflow.com/questions/68037392/why-do-items-match-in-fuse-js-if-the-pattern-contians-a-letter-that-doesnt-exis, Fuse uses Levenshtein distance, and it is not possible to achieve what I want.
Do you guys confirm? Am I the only one frustrated by this behavior?
Thank you
Desired solution
I'd like Fuse to always respect the order of the letters in the searched term. For my specific example, the searched word
metric
should not return as a match the wordcluster
.Alternatives considered
According to the mentioned thread, a different library (not sure I can mention here, but it's in the link) would solve the problem. I found this thread that seems to discuss a similar topic, but with no actual solution to my specific problem: #41
Additional context
No response
The text was updated successfully, but these errors were encountered: