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