file_finder: Refactor found_path to make it compatible with opened files outside of current project

[bnjjj]

This is a first refactoring PR in attempt to merge a fix for #24670. This is following this comment

Release Notes:

• N/A

[bnjjj]

@maxdeviant Can I get a review ? I think you're the one with more context as you were part of the original one.

[ConradIrwin]

@bnjjj If the files are already opened, you should be able to get a project path for them already. Am I missing something about the repro steps, or is it the case that this is for closed files?

[bnjjj]

Open a file outside of your workspace like in your home directory for example. My use case is I open a rust project in $HOME/rust/myproject then I open a file directly from this workspace using open new file action located in $HOME/config.yaml. If I open the file finder it will be listed but once I start to type "co" for example it disappears

[ConradIrwin]

Ah, makes sense.

I think the problem might be that we filter these files out here: https://github.com/zed-industries/zed/blob/9335d91e4c2b3e71c23ea2c1b6a0050a5e7932c1/crates/file_finder/src/file_finder.rs#L870 where we check for the worktree being visible.

Currently it's the case that work trees you manually add to the project (usually just the main project directory) are visible, but any singleton files are invisible.

We might be able to fix the case you describe by adding || .is_single_file() to this check (though I haven't tested it)

However, this would cause files opened by "go to definition" (e.g. stuff inside node_modules) that you still have open to still show up here. Maybe they should too? It definitely seems like they should have the same bug that you describe...

[bnjjj]

Closing this one in favor of #39911