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.

[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.

[ericchase]

still waiting for expand all folders feature 5 years later

edit:
took me all night, but finally figured out how to build this disaster and then apply the expand
video: https://ericchase.github.io/web--serve/videos/2024-05-28_08.24.36.mp4

pretty simple changes

edit 2:
i realized that expanding 3 layers isn't very impressive, and there's already a semi feature to expand nodes that were previously expanded by the user. so here's a video using it on vscode's code base. notice that expanding such a massive code base is exponentially slower (obvious from the lazy reasoning of what one of the, I presume, devs has stated before on this topic), due to having to load all those files/folders (not sure why vscode works this way when other file explorers can recurse directory listings instantly)
video: https://ericchase.github.io/web--serve/videos/2024-05-28_08.30.54.mp4

[starball5]

Did this get addressed recently? I'm on 1.94 and find widget searches into collapsed folders.

[Delapouite]

@starball5 I think you're referring to this announcement in the article https://code.visualstudio.com/updates/v1_94#_find-in-explorer

[richbaines]

I've just tested on 1.94 and it looks like this is resolved! Thanks for the heads up @starball5

[gjsjohnmurray]

I've just tested on 1.94 and it looks like this is resolved! Thanks for the heads up @starball5

Unfortunately for people using extensions that rely on the FileSystemProvider API the 1.94 changes are likely to have broken Explorer Find entirely:

#230483

[Gosstik]

I work in a VERY large repository and searching recursively through all files takes too much time since version 1.94. Previously, I opened only the folders I needed and searched through them - it was very convenient and the search was carried out instantly. Is it possible to return the previous find logic in explorer in the settings?

[rzasukhin]

Just implement it as in xCode. PLease. It cannot be hard.

You should filter-out EMPTY folders without files after filtering.