Explorer: resolve all folders before filtering

[letmaik]

Recently, support for filtering in Explorer by typing parts of a file or folder name was added (#66497). There are two modes:

The default mode simply highlights all matches in currently expanded folders and scrolls to the first found match. Works perfectly, nicely engineered.

By activating the "Filter on Type" mode, the tree gets pruned to only those elements that match the filter. However, this pruning currently removes all folders which had not been expanded at least once before-hand, no matter if they contain a match or not.

In my opinion, the behavior of the Filter on Type mode is counterintuitive as the results shouldn't depend on how the developer has interacted with the tree in advance. At least then there should be some indication on which folders were not considered in the search. In my case, I commonly want to filter on specific file types, and since there is no "Expand All" feature in the Explorer, the current work-around would be to manually expand all folders upfront and then use the new filter feature so that I can be sure that no entries are missing.

I'm assuming this is related to the fact that folder nodes are lazily resolved since they might be remote resources. On the other hand, the normal search functionality seems to have no problem with these scenarios, probably because the expectation is that it's OK to wait a bit until you get the results, whereas here you more or less want it immediately. Maybe a hybrid would be a good solution: do the quick filtering as it is and display that immediately, and in the background start a regular filename search backed by (still experimental) search provider API. Then merge these when the results come in.

@isidorn

[isidorn]

Thanks for the feature request. In the future no need for such a long explanation - being concise is awesome.
This would be an configuration (or a toggle in the filter). And I would do it only for the explorer, since some trees could not even handle resolving everything (like the debug trees - too many requests to the adapter).

fyi @joaomoreno

[eamodio]

@isidorn even in the Explorer sidebar it may be very problematic to attempt to search all folders -- because it would be highly dependent on what any FileSystemProviders are doing behind the scenes.

Don't get me wrong -- I would like to see this feature too, but maybe it has to be limited to non-FileSystemProviders -- or a FileSystemProvider would need to express if it can be supported and/or limit the depth?

[joaomoreno]

Additionally, this feature should be the offspring of a marriage between Explorer and Search, since the latter can provide with file names much much faster than we could ever do in the Explorer model.

[Blum]

I would use the "Quick Open" functionality to achieve this result.
I mean something like:

1. Ctrl+p - to open the "Quick Open" window
2. Start with some prefix like "//" to tell you want folders instead of files. Type part of folder name after that so you get list of matching folders.
3. Select one, and it focuses the explorer with that folder open.

I also like the explorer with Filter keyboard navigation, but since it gets only the currently visible folders, it is not very useful to me.

[sandipchitale]

This extension may be helpful: https://marketplace.visualstudio.com/items?itemName=sandipchitale.revealfolder

[Gruntfuggly]

I hadn't quite realised how fundamentally broken this is. I was pulling my hair trying to work out why I couldn't locate a file that I added yesterday. Needing to expand the containing folder first means I might as well not have bothered.

Could there at least be some indication that a folder contains unresolved nodes?

At the moment there is just the note in the January release note - there are probably lots of users who won't find this and it leaves a pretty bad impression.

[quolpr]

Any plans on this feature? I cry when I can't find needed file/directory because it is not expanded 😄️

[majkinetor]

The filtering is basically unusable because of this. Alternative is CTRL+P anywayz.

[TristisOris]

to find any file i need to know this file path. That exactly how search should work.
4 years for basic feature?

[dlschmidt]

@TristisOris it is not that simple because the explorer view is asynchronously fetching data as needed afaik

but yes, this should have been fixed already

[starball5]

Related on Stack Overflow:

• How can I expand all files in VS Code's Explorer View?
• Is it possible to expand items in VS Code's Explorer View recursively when using its "Filter on Type" feature?
• VSCode: CTRL+F in the Explorer facility does not seem to be working, or is working in a practically useless way

[RuslanZasukhin]

I do not understand why developers see any performance problems in doing it in the "right way".
Xcode does it in zero time for our HUGE projects with hundreds of folders and thousands of files.
Please just try and see. Another example - SmartGit - java based app, also filters the same project instantly.
I do not care about you "asynchronously" if this works in the wrong nasty way!
Just do THIS task synchronously :)

In my report (already closed by the team) I have made a few pictures of how nicely do this xCode.
#179600

[david-fong]

@fshafiee

1. The previous search result is not preserved and one must retype the query every time.

Use "workbench.quickOpen.preserveInput": true,.

2. The recent activities keep piling on top and gets harder to access the next un-reviewed file.

Consider using "search.quickOpen.includeHistory": false,.

[NeuralSixty]

Unfortunately I'm in a situation where our stakeholders are getting impatient and we'll start having problems if they still can't filter nested tree structures without manually clicking on every single unresolved folder to see if its contents match the filter, so obviously I am motivated to see this issue getting resolved. Not to mention they now have to focus on the view and then press Ctrl+F instead of previously having a search bar, but that's a different matter.

It seems to be that there are some concerns going on preventing this feature from being released:

1. Some trees might not be able to resolve every node - Explorer: resolve all folders before filtering #66971 (comment);
2. Filtering is dependent on what a FileSystemProvider is doing under the hood - Explorer: resolve all folders before filtering #66971 (comment);
3. The explorer view (or any other view for that matter) is doing the fetching in an async manner - Explorer: resolve all folders before filtering #66971 (comment);
4. Recursive find in async trees is not yet supported - Project Tree Filter (Files) Should not show folders without results and more... Like in Xcode. #179600 (comment).

If I understand correctly:

--> Recursive find in async trees is not supported, because
----> Fetching is done in an async manner, which
------> Depends on what the fetching mechanism is doing under the hood, therefore
--------> Some trees might not be able to resolve every node

Is this what's actually going on? If so, I'd like to contribute to seeing this closed. I'm already neck-deep over an open GitHub issue as it is.

[nistre]

Just checking. Is there any update to this open issue since June other than being reported by other users?

[maestrow]

Initially, I wanted to get files filtering feature to filter out all package.json file and open them at once in VSCode. Finally, I came to following bash script:

function openAllPackageJson {
  local list=$(find . -type d \( -name node_modules -o -name dist \) -prune -o -name package.json -print)
  code ${list[*]// /|}
}

May be someone else also will find it usefull.

[xinhaizhixue]

This feature still feels terrible, but I found an alternative, if searching for directories you can use the extension 'Reveal matching folder in Explorer view', if searching for files you can use crtl+p or cmd + p

[ivanglushko]

Thats exactly what i was expecting while using filter feature in explorer. Expecting to filter RECURSIVELY that's the main point.
For now i'm using just a shell command like find . -type f -name "*.json" but the ui in terminal is ugly. Would be awesome to have this feature in VSCode so i could ditch terminal at all. Btw maybe it's suitable for search tab aswell

[ADTC]

Don't really get why this clumsy approach still exists and isn't replaced by what's naturally expected: filter everything and show me just the matches.

If the Search pane can quickly search through the contents of all files in the project (even if the default exclude is disabled), isn't it comparatively even faster to search just the file names? I shouldn't have to open "untraversed" folders manually.

What's the performance issue? Is it still relevant in the latest VS Code?

[scott-parkhill]

@ADTC for real.

[tjamin]

You can use the search feature as a workaround: https://stackoverflow.com/a/77913729/1536921

[jrcsdev]

This is something so useful and necessary. I switched from Visual Studio to VSCode, but I run into this problem. I'd honestly rather lose a little performance than have to open all the folders manually to get the search to work. Even having to press CTRL+F to see the search bar is unintuitive. Visual Studio's file explorer does it much better. If we had that same explorer in VSCode, everything would be fine.

[amhci]

Don't really get why this clumsy approach still exists and isn't replaced by what's naturally expected: filter everything and show me just the matches.

If the Search pane can quickly search through the contents of all files in the project (even if the default exclude is disabled), isn't it comparatively even faster to search just the file names? I shouldn't have to open "untraversed" folders manually.

What's the performance issue? Is it still relevant in the latest VS Code?

I just found this thread after searching for how to use this handy little search box to search across all the files in my project. I'm blown away that this issue has been open for so long! And I just also found out I can't expand all folders!

+1 to this issue, FWIW

[hakan-akgul]

I have a workaround solution.

1. Install extension: DK189.vscode-files-explorer
   a. Right click to folder that you want to expand. It is enough to make once when you open workspace first time
   b. Now you can search/filter all files easily
   c. Or you can search/filter the new listview

2. Exclude flies you don't want to filter. You can make it via:
   a. Find in workspace settings files.exclude
   b. Or you can install extension to make it fast: PeterSchmalfeldt.explorer-exclude. Right click and Add to Hidden Items...
   c. If hidden files are shown in listview, reload vscode

3. To make process faster you can assign a shortcut - OPTIONAL
   a. Open settings and update the settings workbench.list.openMode -> filter
   b. Press cmd+shift+p and find Open Keyboard Shorcuts (JSON)
   c. Add this codeblock here and update the keys you want to:

 {
   "command": "runCommands",
   "key": "cmd+y",
   "args": {
     "commands": [
       "workbench.explorer.fileView.focus",
       "list.find"
     ]
   }
 },
 {
   "command": "runCommands",
   "key": "cmd+shift+y",
   "args": {
     "commands": [
       "vscode-files-explorer.views.files-explorer-list.focus",
       "list.find"
     ]
   }
 },
 {
   "key": "cmd+shift+y",
   "command": "workbench.action.closeSidebar",
   "when": "sideBarVisible"
 },

[ArtemAvramenko]

@hakan-akgul I don't quite understand why explorer-exclude should be installed? Files can be excluded via the settings file (file.exclude and search.exclude options) without third-party extensions

[hakan-akgul]

@hakan-akgul I don't quite understand why explorer-exclude should be installed? Files can be excluded via the settings file (file.exclude and search.exclude options) without third-party extensions

Yes you are right. But it is easy to right click and hide. Also you can unhide directly when you need the file. I will update the comment. Thank you!

[hakan-akgul]

I return with a different paradigm.

For a while I'm using rust baseed terminal app broot.

Fast, preview support, fuzzy search. Also it filter lines in preview mode...
Highly recommended. Give a chance.
No need to open side panel for explore files.

[ivanglushko]

For a while I'm using rust baseed terminal app broot.

Thanks for letting us know (will try it out) I tend to use Zed (Rust based) in recent times. It's still in early days but already so good.