Support fuzzy matching on the absolute paths of files/resources

[DavidGoldman]

We now apply fuzzy matching on the (absolute) path of files/resources,
which allows fuzzy matching to work even if the user has a partial
absolute path or subpath which is rooted in folders outside of the
workspace folders.

I left a FIXME in the code - I'm not sure if we should try to add a minimum score threshold or maybe think of another way to avoid really fuzzy matches (e.g. typing someRelativelyLongString and having tiny matches across tens of path components due to long absolute paths). Please let me know what you think.

[DavidGoldman]

It looks like the tests are failing due to changes in the search behavior causing more results than before especially for simple searches - maybe to work around this, we should only do this behavior for searched contains path separators? Any opinions?

[DavidGoldman]

The remaining test failures are because the fuzzy matching now gives many more matches since short queries like site.* in FileSearchEngine Files: *.* without derived: match against fragments of path components. Any suggestions on how to improve this? Maybe we shouldn't we shouldn't support fuzzy matching on the absolute paths, only exact matches?

[bpasero]

What is the issue this is trying to address?

[vscodenpa]

This issue has been closed automatically because it needs more information and has not had recent activity. See also our issue reporting guidelines.

Happy Coding!

[DavidGoldman]

Sorry, missed this. The main motivation is that we have files in our code-workspaces which are referenced currently via their folder-relative path, but in many places elsewhere, the paths given are relative to the monorepo. This causes issues when searching, since the monorepo path is longer than the relative path and then search doesn't work.