I would like to request the child: function (and any of its siblings) please support multiple patterns so that it can find all matches in one pass.
One of my most frequent search tasks involves searching a grouping upwards of 30 to 50 keywords with the child: function, so to display folders that contain matching files. This takes a long time as Everything has to perform 30 to 50 index enumeration passes, one per keyword, instead of detecting for all keyword cases in a single pass.
My syntax looks like this:
"X:\Fruit\" <child:apples_*.doc|child:oranges_*.doc|child:bananas_*.doc|child:grapefruit_*.doc>
My desired syntax should look something like this:
"X:\Fruit\" child:"apples_*.doc|oranges_*.doc|bananas_*.doc|grapefruit_*.doc"
[ As an aside, Everything has an unfortunate quality to it when the option [x] Search As You Type is enabled, which becomes extremely obvious when stacking 30 to 50 child: requests. Typing additional characters to the search bar will flush the results and immediately start over, lagging the input of additionally typed characters until the first child: function completes and then it flushes and starts over again, wash rinse repeat, without any pause or consideration for the user typing. I feel like there should be a 2-3 second delay between the user's final keystroke before beginning the search if there are more than 50 characters in the search bar, or, temporarily disable the option "Search As You Type" if there are more than 5 recursive functions in the search bar. Or Something. ]
child:<multiple|search|patterns> or Recursive Hell
Re: child:<multiple|search|patterns> or Recursive Hell
Your best bet for now would be using regular expressions.
Then you can search for:
- or -
(should be faster)
Same with searching for content, btw: When searching for files that contain the text "something", Everything takes off straightaway after entering content:s to fetch files and doesn't come back for a while. (that is also on the to-do list)
To work around that, I deliberately make a typo, like connntent:something and fix the typo at the end.
Not a feasible workaround with 30 child: functions though ...
Then you can search for:
Code: Select all
"X:\Fruit\" regex:child:(apples|oranges|bananas|grapefruit)_.*\.doc
Code: Select all
"X:\Fruit\" regex:child:^(apples|oranges|bananas|grapefruit)_.*\.doc$
IIRC, that is on the to-do list.raccoon wrote: ↑Thu Jan 21, 2021 3:20 pm [ As an aside, Everything has an unfortunate quality to it when the option [x] Search As You Type is enabled, which becomes extremely obvious when stacking 30 to 50 child: requests. Typing additional characters to the search bar will flush the results and immediately start over, lagging the input of additionally typed characters until the first child: function completes and then it flushes and starts over again, wash rinse repeat, without any pause or consideration for the user typing. I feel like there should be a 2-3 second delay between the user's final keystroke before beginning the search if there are more than 50 characters in the search bar, or, temporarily disable the option "Search As You Type" if there are more than 5 recursive functions in the search bar. Or Something. ]
Same with searching for content, btw: When searching for files that contain the text "something", Everything takes off straightaway after entering content:s to fetch files and doesn't come back for a while. (that is also on the to-do list)
To work around that, I deliberately make a typo, like connntent:something and fix the typo at the end.
Not a feasible workaround with 30 child: functions though ...
Re: child:<multiple|search|patterns> or Recursive Hell
Thanks for the regex:child:<pattern> tip! I was not aware or somehow missed/forgot that these functions supported regex patterns in this manner. Intuitively I had already tried child:regex:<pattern> which does not work, and so I wrote it off.
I do wonder if there are any blocking syntax incompatibilities that are preventing child: from supporting multiple terms. It seems like the type of search term alternation ("apple|orange|banana") would be a low level function that's common to all of Everything's high level functions. Has void ever commented on why most functions only support a single term?
I do wonder if there are any blocking syntax incompatibilities that are preventing child: from supporting multiple terms. It seems like the type of search term alternation ("apple|orange|banana") would be a low level function that's common to all of Everything's high level functions. Has void ever commented on why most functions only support a single term?