Order of files in "Search files by name" results is incorrect

[adamreisnz]

• VSCode Version: 1.44.1
• OS Version: OS X 10.15.3 (Catalina)

Steps to Reproduce:

1. Create two files in your work space: foo.bar.js and other-footer.other-bar.js
2. Press CMD-P to bring up the search by files dialog
3. Search for a file which has pattern foo.bar.js by typing foo bar

Expected result:

For the file foo.bar.js to come out on top in the results, because:

• It's a shorter file name
• Relatively, more characters of the whole filename string match the search query
• The two search terms foo and bar are positioned closer together
• The filename starts with foo, just as the search term does
• The word foo is present in that filename, instead of footer

I can't find any logic that would score the other filename as a better match for this search term than the short one.

Does this issue occur when all extensions are disabled?: Yes

Other examples:

[adamreisnz]

Here's another example where the order of files just boggles my mind:

The first result is way longer, much more entropy, doesn't start with the search term, and even splits up the search term, whereas the second result is a perfect fit.

I think this used to be much better in a previous release, I don't recall this happening before.

[lleheny0]

Coming from Atom, this is jarring. I have to type way more words to narrow the results down, and then hit the down arrow a bunch of times to get the file I actually want. With Atom, I have to type maybe 3 words max and hit enter because the file I want is at the top of the list.

[bpasero]

If you separate query input by spaces, each one will be used as individual query on the entire thing. Does it change anything if you stop using space to separate? You do not need to use spaces at all unless you explicitly want to filter by folder e.g.

[adamreisnz]

I've been using spaces to delimit searches for 10+ years now. It's a lot faster and easier to type than a dash or a dot or whatever, and it used to work great, and works great in other editors. Would just like this functionality to be restored to what it was before and for the results to be prioritised a bit better according to length, entropy, etc..

A space should just be considered a generic delimiter imo, and the search results I'm getting now and which I've screenshotted above just don't make any sense to me.

Google and other search engines allow us to delimit search queries by spaces and doesn't seem to have any issues with it either, so I'm sure it's doable to take it into account.

[bpasero]

A little bit more background on the change to consider space as separate queries is given here: https://code.visualstudio.com/updates/v1_44#_quick-open-rewrite

Given you seem to want the previous behaviour, I am renaming this to reflect that and add this to the list of issues in #27317.

[bpasero]

Upon second thoughts and looks, I have revisited the sorting algorithm as I agree the results are quite bad in this case. In the end what caused the bad sorting is that we used the following algorithm from top to bottom:

• prefer 100% identity matches
• prefer prefix matches
• prefer camelcase matches
• prefer any fuzzy match

Somehow foo was matching camelcase style and looking at the implementation (which I did not write), I cannot really explain that. My change in 611f6f9 is to drop the special treatment of prefix and camelcase matches and simply rely on the fuzzy match scorer to compute the score. I feel it is mature enough to solve this task:

• prefer 100% identity matches
• prefer any fuzzy match

Have to watch out for regressions though, but I added all your cases as test cases to our test suite.

[bpasero]

@adamreisnz this change is now live in our insiders release if you want to verify it. You can give our preview releases a try from: https://code.visualstudio.com/insiders/

[adamreisnz]

Thanks, I will check on Monday

…

On Fri, 14 Aug 2020, 20:05 Benjamin Pasero, ***@***.***> wrote: @adamreisnz <https://github.com/adamreisnz> this change is now live in our insiders release if you want to verify it. You can give our preview releases a try from: https://code.visualstudio.com/insiders/ — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#103052 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AADXYQRUTVVTPPDVRPGOSXDSATV4VANCNFSM4PEELTEQ> .

[adamreisnz]

Yep I can confirm it's much better now, thank you!

[roblourens]

@bpasero here's a weird new case in Insiders (i'm looking for main.ts, in the middle)

Stable:

[bpasero]

Thanks for reporting this, my changes were maybe a bit too aggressive. Truth is that we prefer results that entirely match in the label over those that match in description (related issue: #25925).

In my previous change I removed both the camel-case-matcher as well as the prefix-matcher for the label, but I have now restored the prefix-boost to not break things too much.

Bottom line: if a query matches on the prefix of a label of an item it will always win over other matches assuming that this is the most accurate match.