-
Notifications
You must be signed in to change notification settings - Fork 52
Open
Description
We've been attempting to replace zed's fuzzy matcher with nucleo, and have run into some unexpected result ordering when using prefer_prefix = true. In our tests, candidates with a prefix from the query were scored higher even when the match_indices indicate that the start of the string wasn't part of the match. See the below test for an example:
#[test]
fn same_score() {
let paths = ["lsp_code_lens", "code_lens"];
let mut config = Config::DEFAULT;
config.prefer_prefix = true;
let mut matcher = Matcher::new(config);
let pat = Pattern::parse("lens", CaseMatching::Ignore, Normalization::Smart);
let matches = paths.map(|p| {
let mut indices = Vec::new();
let mut candidate = Vec::new();
let score = pat
.indices(
crate::Utf32Str::new(p, &mut candidate),
&mut matcher,
&mut indices,
)
.unwrap();
(p, score, indices)
});
dbg!(&matches);
assert_eq!(matches[0].1, matches[1].1);
}outputs:
---- tests::same_score stdout ----
[matcher/src/tests.rs:793:5] &matches = [
(
"lsp_code_lens",
107,
[
9,
10,
11,
12,
],
),
(
"code_lens",
105,
[
5,
6,
7,
8,
],
),
]
Our question: is this working as intended? We would have expected them to return the same score (and they do if you remove the first "l" from "lsp_code_lens"). Some of our applications of fuzzy matching such as code completion rely on this behavior, and if it's not a bug we'd love a way to customize it.
Reactions are currently unavailable
Metadata
Metadata
Assignees
Labels
No labels