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.

[kenbankspeng]

I suggest a 'recursively expand all' is not necessary to fulfill the practical use case. Would just like to have 'expand all my folders of interest'.

I don't mind going through once and recursively opening up all my folders of interest manually. I will not be opening 20,000 folders/files. Convert the 'Collapse Folders' into a toggle between 'Collapse All Folders' / 'Re-open Folders that I previously opened' and the problem is solved, without big performance concerns of 'recursively expand all'.

[Deadarius]

Qould be awesome to have this. CMD+P is not a viable alternative for a following usecase: I want to quickly browse through all files containing a specific substring in their names.

[mosesoak]

Sidebar on "recursively expand all", often shot down as a perf nightmare:

Accessing folders is most likely already async. So could the recursion not be time-buffered, and potentially also queue-prioritized? (The the kind of optimization we've all seen FB's React team tackle to incredible gain.)

UX examples:

• If pre-indexing is helpful, run it in the bg after an inactivity delay - low-impact, low-priority, UI not slowed.
• When you begin typing to search for a folder:
  • do show the available (known) results immediately
  • but also show an 'indexing...' marker (perhaps with a % complete if that's knowable) if not, and continue to populate results as they come in
• Alt-click to 'expand all', a much-wanted feature (#9456, #18109, #68943, etc.) that currently doesn't work past what has been previously expanded, could now also be implemented:
  • first the folder index could be used to draw all the known folders/contents, so in normal apps that would probably be everything
  • known folders with unknown contents could show a 'working...' link, so you could click to prioritize that to top of work queue
  • then non-indexed folders and contents would appear to cascade open gradually, level by level. For normal apps this would just take a second or two.
  • For very large file systems taking a long time, maybe there's a UI provided like 'expanding...' with a stop X.

Single-threaded management like this is hard but achievable!

Food for thought? I'm not a VS Code core-team dev by any means, so apologies if this is off base!

[ADTC]

Sub-par experience.

• Having to expand all folders manually before filtering makes no sense.
• Having no search bar in Explorer to filter makes no sense.
• ~Having to click "Enable Filter on Type" after typing makes no sense (I want filter to be on by default).~
  • Setting workbench.list.keyboardNavigation to filter fixed this. Thanks @gjsjohnmurray
• The headache is compounded by the fact that there is no "Expand All" button on the Explorer pane, and that the Search pane doesn't search file names.

Is there any extension that can force expand the entire folder tree and optionally collapse it again at start-up so that the filtering works correctly? Is it possible to build one?

PS: Consider excluding node_modules folder by default on all new VS Code installations. This is a folder that's well-known to contain things that don't need to be visible in an IDE, just like the .git folder.

[gjsjohnmurray]

• Having to click "Enable Filter on Type" after typing makes no sense (I want filter to be on by default).

@ADTC does "workbench.list.keyboardNavigation": "filter" help you?

[KPatel91]

I would love this! I use filtering in explorer so much and have only just realised today that it only filters based on what's already opened out. Was driving me a bit crazy thinking VS was broken until the penny dropped.

I get that there might be perf issues allowing the whole file-tree to be searched / expanded - but an option at least would be awesome, for those in small directories 😄

[MichaelAaronWilson]

I was struggling with this also until I found a good workaround...open the project folder in Visual Studio (not Code) and search in the Solution Explorer 🤷😂

[esaith]

I was struggling with this also until I found a good workaround...open the project folder in Visual Studio (not Code) and search in the Solution Explorer 🤷😂

I love this response since this is what I do. I use another program because the current one doesn't make sense. Not every project has 10,000+ folders and using the CTRL + P is barely helpful when I want to spam open 10 documents based on file extension. I have to copy/paste my search query for CTRL + P to improve my search productivity. I'm not sure which wastes more time.

If I need to view/update multiple .spec.ts files because of a DI service or the framework has been updated, I'd like to be able to quickly jump from one .spec.ts file to the next. Having a filtered list is nice. Having to manually expand every directory to get the same functionality is not nice.

It's a lot easier to open VS Code for the first time of the day and immediately filtering through files rather than spending a few minutes manually expanding all my directories. How is that UX helpful?

Until this is fixed, the best solution is not to use this product when I need to work in a specific way.

If CTRL + P can do it without a performance hit, then no reason why the filtering can't do the same. The difference is that filtering does not lose my filtered list after selecting a file.

[fshafiee]

If CTRL + P can do it without a performance hit, then no reason why the filtering can't do the same. The difference is that filtering does not lose my filtered list after selecting a file.

I came to say the same thing @esaith.

If I have to expand every single folder (given how few files each folder may contain which is the tendency these days), then I can just click on the file rather than to stop clicking and start typing.

My current solution may be the most unorthodox of all, as I use find command inside terminal to pre-compile the list. Something like:

find . -type f -name "*.extension"

Or if we are being smart:

find . -type f -name "*.extension" | xargs code

As people have already stated, the Quick Open trick (Ctrl+P) won't cut it if you are going to go through a series of files, because:

1. The previous search result is not preserved and one must retype the query every time.
2. The recent activities keep piling on top and gets harder to access the next un-reviewed file.

So, I have to compile the list outside of VSCode in a stable and predictable form, and then open them one-by-one in the editor.

Very counter-intuitive.

[gjsjohnmurray]

By using the RightArrow key in the Ctrl+P quickpick you can open the highlighted file without closing the quickpick.

And Alt+RightArrow will open the file to the side. If you don't yet have a second editor group, one will be created.

[fshafiee]

@gjsjohnmurray thanks for the tip John. It helps but not in my particular use case to be honest.

In one instance, I had 70+ files that needed to be refactored (they all had a specific extension). Iterating through all of them in Quick pick is ok but it's a slower version of the command I posted.

I still believe having a persisting filtered list of files in the explorer is a superior UX to both of these approaches, as it's easier to retrieve the context or pick up the work if it was interrupted (given how Git extensions changes the color of modified files in the explorer).

[rubper]

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.

I'm currently doing this, is not actually viable as I have to keep pressing Ctrl + P Yes, it works with a single file, not with a pattern of files

[ADTC]

Here's another idea:

@letmaik said: 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.

We can change this behavior!

Instead of removing folders which were never expanded, we can simply show them in the results in a collapsed state. This would indicate the likelihood that VS Code has not yet seen inside (indexed) the folder. (Optionally, such a folder could be slightly greyed out to visually distinguish a non-indexed collapsed folder from an indexed collapsed folder.)

If I'm interested, I can click on the folder to expand it. The folder contents should expand (get indexed), then show the items that only match the filter. If it turns out that there are no matching items, then the folder should disappear from view.

While this is not exactly expanding/resolving all folders before filtering, it will at least be a good starting point to reduce the confusion created by current behavior.

Bonus point: The new behavior would be very similar to what happens when all folders had been expanded at least once, then collapsed again before filtering. Folders with matches remain visible but collapsed. A click on such a folder would expand it and show the matches inside it. Folders with no matches disappear from the tree. We're simply adding a third case: Folders with unknown matches also remain visible but collapsed (and maybe in a greyed out state).

[gjsjohnmurray]

@joaomoreno @lramos15 what do you think about trying the idea @ADTC posted? Instead of excluding a folder that hasn't yet been resolved, include it in the results of the filter/find, ideally with a decoration to indicate that its inclusion is provisional. If I want to resolve the uncertainty about one of these folders I can expand it explicitly. When it's contents return, reapply the find/filter.

[icetbr]

My workaround, I search a regex matching the beginning of a file. Ex: I want to see all readme files from my projects:

CTRL + SHIFT + F => ALT + R => paste regex ^(?<!\n) => files to include README.MD

[ADTC]

@gjsjohnmurray thank you for your support.

@icetbr nice trick, though for partial matches, we need asterisks: *ADME*

Additional comments:

The Search module searches for all files including their file contents but the Explorer module refuses to search initially-collapsed folders citing performance issue, despite only looking at file names (not contents). Wouldn't the same performance issue be magnified for Search since it greps the contents?

There is one argument that if the option "Use Exclude Settings and Ignore Files" is turned on, the Search module's performance is improved. Couldn't the same option be utilized in the Explorer module too, to ensure performance without handicapping results? node_modules folder is extremely likely to be mentioned in an ignore file, and we can add it to Exclude Settings as well (if not already there by default).

[scott-parkhill]

I got frustrated with this issue as it just gets worse and worse the larger a project is. Implemented my own hacked together solution if anyone wants it (and is like me and always has the integrated terminal open lol).

https://github.com/scott-parkhill/file-find

[gjsjohnmurray]

I just submitted PR #164472 which implements an idea suggested by @ADTC.

[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. https://github.com/microsoft/vscode/issues/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 - https://github.com/microsoft/vscode/issues/66971#issuecomment-456744675;
2. Filtering is dependent on what a FileSystemProvider is doing under the hood - https://github.com/microsoft/vscode/issues/66971#issuecomment-457676293;
3. The explorer view (or any other view for that matter) is doing the fetching in an async manner - https://github.com/microsoft/vscode/issues/66971#issuecomment-1509859246;
4. Recursive find in async trees is not yet supported - https://github.com/microsoft/vscode/issues/179600#issuecomment-1520407721.

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.

[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