Improved search in "Go to file" panel

[alexandernanberg]

Would love to see a more accurate search for what I'm actually searching for. For example when I'm searching for "archive" and I'am in mid sentence i get these results:

I think, at least for me that the index.js inside the archive folder file is much more relevant than the .babelrc and yarn.lock. Sublime on the other hand does exactly what I want.

This change would make the workflow with VS Code even better than it already is 😄

[chrmarti]

We use the path only as tiebreaker, that makes filenames with non-consecutive matches win against paths with consecutive matches here.

[bpasero]

Also https://github.com/Microsoft/vscode/issues/35572#issuecomment-339282965

[grothkopp]

Thank you @bpasero. I like to add that lots of web frameworks like symfony have lots of files with identical names in different directories (indexSuccess.php, etc).

[bpasero]

@grothkopp this is only an issue if your query happens to fully match on the file name. once your query has enough significant characters from the parent folders it should not happen anymore.

[grothkopp]

@bpasero yes, but as my screenshot shows its easy to fully match the individual characters in long file names.

And partial matches in filesnames still have precedence (see my screeshot: oneshotRecurringTask.class.php in lib/task ranks before _betrag.php in lioshop)

There's also the issue with "greedyness" (the last p in php matching instead of the p in the path).

[grothkopp]

I just noticed that adding a trainling slash after the directory name ( "lioshop/") solves the problem in the insider build.

But I think thats more a workaround than a solution.

[bpasero]

@grothkopp yes good point, if you include a path separator, the matching on the file name alone will no longer happen.

[chrmarti]

I would like to see us make progress here, but don't have the necessary time at the moment. Some care will be needed, because with large projects the sorting affects performance.

[EmmaSimon]

I'm not sure if this should be a different issue, but I'd also like to see independent fuzzy finding for multiple words. This was added in sublime recently, and I miss it in other editors. https://forum.sublimetext.com/t/dev-build-3154/33286

Also changed in 3154 is the fuzzy matching algorithm (as used by the Command Palette and Goto Anything), where you can now enter space separated terms, and each will be matched independently. e.g., "hw" will match "Hello World", and now "w h" will also match it (but "wh" would not).

For a more specific example, I have some files in a /reducers directory, and whenever I want one I usually type user reducer, and since reducer is before user in the file path, the file isn't found.

[bpasero]

Yes, https://github.com/microsoft/vscode/issues/25925#issuecomment-357261679 should be covered with https://github.com/microsoft/vscode/issues/30404

[garygreen]

Any progress on this? It's been 3 years and Sublime still outclasses VSCode when it comes to fuzzy search matching in a intuitive way. Would be super awesome if more focus could be made on improving this. I think a lot of developers would appreciate it 👍

[ses4j]

Is it possible to write an extension to replace the file search provider? I agree with many previous commenters that Sublime's gets it right so much more often than VS Code's... i really miss it. One piece of the algorithm that I think is sorely missing is that a search like hw should match hello_world.py better than it matches howto.py, by recognizing that underscores (or camelcase, etc) are natural word breaks and first letters of words are more important than others...

[mattaningram]

Another example screenshot showing that path names should not be used just as tie breakers. Path name exact string matches should appear higher than simply finding all the letters somewhere in the filename. This is just confusing:

[pforhan]

Is there a separate issue about sorting case-sensitive matches higher? Let me know. For example, I'd like to see HelpAppletClientActionTranslatorTest bubble up to the top here:

[rcywongaa]

Since users are more likely to jump to files related to the code they are currently editing, we could borrow some ideas from https://github.com/microsoft/vscode/issues/80444, in particular, order by proximity to currently editing file would seem like a low hanging fruit

I've had great success using fzf with proximity-sort

[JUSTIVE]

I'm having similar needs as @pforhan . I want to access my files with their initial letters, not just any matching files

[mrmachine]

Bringing my comments from the closed as duplicate issue above so they can add to the conversation.

It's not only Sublime Text that gets it right. GitHub does a way better job and basically does pretty much exactly what I expect every time I use it.

Surely it should not be too hard for MS to copy the implementation from GH, which has VS Code baked into it, which they also own, and which runs in a web browser without performance issues?

It is disheartening to see that this issue is still open after nearly 7 and a half years.

Original comments below:

I always have terrible results with the VS Code Quick Open feature, and excellent results with the GitHub "go to file" feature.

For example, I want to jump to a file djangosite/urls/default.py so I Quick Open and type urldef, but I get this soup in VS Code:

In GitHub with "go to file", I get exactly what I want:

If I try to separate the two fragments with a space url def (and even try reversing them to def url thinking the first fragment might better match the filename and then be narrowed by path), I get better results, but still the best match is 4th down on the list below what appear to be lower quality matches:

Why does a 3 consecutive character match from the start of the parent directory and covering 75% of the parent directory name (urls) not trump 3x single character matches from anywhere inside separate path fragments? The individually matching characters make up a tiny percentage of the overall length of each fragment, and some are not even matching anywhere near the start of the fragment.

This is my experience often with VS Code where I have to ignore and visually scan past a long list of garbage matches to find the one I actually want. Which is infuriating with the GitHub implementation nails it pretty much every time.

[bpasero]

This is a good example, thanks for sharing. In both cases our algorithm prefers a better performing match in the file name over a match in the full path and that is the root cause of many issues. Addressing this would mean to give up on the separation between file name matches and path matches and focus only on path matches I think.

[bpasero]

@mrmachine a way to force VS Code into matching on the entire path is to separate segments with /, i.e. in your case can you try url/def?

[mrmachine]

@bpasero yes, that works much better, thanks!

I would not say that completely fixes the issue because it is still inconsistent with GitHub which is strange considering you can open VSCode directly in the browser from GitHub with . and it is also a little slower and more cumbersome to type and another unintuitive thing to remember to do and odd that a space as the separator doesn't have the same effect as /

[mrmachine]

I would also suggest that in response to your comment about the algorithm preferring a better match in the filename, that these "better" filename matches shown in my earlier screenshots are not actually better at all considering that pretty much ALL of the top matches include single isolated character matches in the middle of a word in the filename which is extremely low value.

[lhnrd]

Any news about this feature? I'd love to see a plug n play kind of option to improve the search. Often I can't find the file in a big project.

[jojva]

@bpasero,

In both cases our algorithm prefers a better performing match in the file name over a match in the full path and that is the root cause of many issues.

I find myself having the same issue as many of these people. I'm not sure why VSCode favors the filename over the full path. It seems like one of those things where the algo tries to be smarter than it should be, leading to worse results.

So here are my questions:

1. is there a rationale for this?
2. is it set in stone, or is it open for discussion?
3. would a setting enabling full path fuzzy search be a possibility?
4. is there any alternative or workaround?