Quick Open should favor file names not folders

[cd-a]

See this example here:

Typing this in the quick open, the file that I would expect to be on top is second to the bottom. Third to the bottom should be the second result.

The others in the top 5 that I would expect aren't even shown on that list.

Is there a setting to change the prioritization during search? I'm used to just typing "Ex" and then i'm there where I want to go

[CrossR]

We utilise Fzy to power the QuickOpen, and they have a decent explanation of their matching algorithm here: https://github.com/jhawthorn/fzy/blob/master/ALGORITHM.md

I think in this specific case, the scores must all be fairly close. The first ones will all recieve bonuses due to matching near two folder seperators, wheras the one you wanted will get a bonus for that and for being near the file extension (I believe). Then since the scores are assumedly very close, the final result ends up favouring the shorter of the results, as that is what is used for cases where the scores are equal.

There is certainly a few more dials we can turn for improving the quick open filtering. However, there isn't currently any form of "prioritise files matches" option, as the strings are scored as a whole, rather than split into path/file. Its certainly something we could look at, and may make sense for an updated UI that splits up the File/path (I.e. file name first, then path, to fit the bar more nicely).

I think part of the issue with getting a consistent quick open filter is getting it to work across a range of different "seach modes". I'm the sort that would search "expirtsx" and hope for the best, whereas that isn't how another set of people will search, and joining those two search styles together is hard. I think looking at adding an option alongside a quickopen UI update could work though, to prioritise searches that score highly on the name vs name + path.

[cd-a]

Thanks for the detailed explanation.

I've checked the algorithm link you included, and it seems to make sense the way you described it.

And yes, I also agree that it depends on the way each individual uses the search.

When I search for "Etsx" I will find what I'm looking for

Same few hits even same for just "esx", and that's great. This is similar to my fzf/vim configuration.

So now I know how to search with extensions to get what I want, thanks!

As a reference, I was used to the way VSCode handled the search.

Here, it favors the file name itself, and also has this "recently opened" at the top to favor results that are being frequently used, which I find quite handy. Is this something that has been considered?