Skip to content

prefer_prefix returns higher score for matches when the prefix isn't part of the matched text #92

@P1n3appl3

Description

@P1n3appl3

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.

@dvdsk

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions