Combining multiple searches

[void]

Everything 1.5.0.1421b adds support for combining multiple searches.

Perform multiple independent searches and combine their results.
Each search is evaluated independently, allowing search functions such as count:, dupe:, and select-all: to be applied before the results are combined.



and-search:
Performs a new search and intersects its results with the current results.

For example:

dupe:size dupe-from:c:\windows\ and-search: !c:\windows\

Find duplicates from c:\windows\, then hide the results from c:\windows\.



or-search:

Performs a new search and unions its results with the current results.

For example:

c:\windows\ count:10 sort:dm or-search: "c:\program files\" count:10 sort:dm

Find the 10 latest files from c:\windows\ and combine them with the latest 10 files from C:\Program Files.

sonic select-all: or-search: tails

Find files whose filename contains sonic and select all of them.
Then find files whose filename contains tails and combine them with the existing results. The tails results remain unselected.

sonic tails select-all: or-search: sonic

Find files whose filename contains sonic and tails and select all of them.
Then find files whose filename contains just sonic and combine them with the existing results. The sonic and tails results remain selected, while just the sonic results remain unselected.



New results are not added when using and-search: or or-search:
Press F5 to refresh a multi-search.

[void]

Everything 1.5.0.1422b fixes an issue with and-search: and or-search: compiling as the same function in release mode.

[therube]

sonic select-all: or-search: tails

So that is the same as

sonic | tails

sans the selections?

[void]

Yes.

A or-search: B

is the same as

A | B

A and-search: B

is the same as

A B

and-search:

and

or-search:

are only useful when using with count:, dupe:, distinct:, unique:, select-all: and other functions that are applied after results are found.

avoid using

and-search:

and

or-search:

for regular searches as performance will be much slower than a simple

<space>

for AND and

|

for OR.

[NotNull]

Some test results with or-search:

PART 1
Query 1 gives the expected results (4 Windows entries; 3 Program Files entries):

Code: Select all

sort:path C:\Windows\* count:4    or-search: "C:\Program Files\*" count:3

Whereas query 2 (without sort:path):

Code: Select all

C:\Windows\* count:4    or-search: "C:\Program Files\*" count:3

just lists the 3 entries from "C:\program files"

... unless ...

Query 1 is executed before query 2. (I suspect some caching/ reusing list entries)

Is the sort:... mandatory when using or-search: / and-search: ?


PART 2:
I also noticed highlighting matching text is onluy applied to the last part of the search (in this case C:\Program Files in the Path column.
Guess this is inevitable?


PART 3:

Code: Select all

"C:\program files\*" count:3  or-search: C:\Windows\* count:2  or-search: "C:\ProgramData\*" count:2

Shows no results at all

Code: Select all

sort:path "C:\program files\*" count:3  or-search: C:\Windows\* count:2  or-search: "C:\ProgramData\*" count:2

Shows 3 resp. 2 results from the first 2 folders, but none from the C:\ProgramData folder.
And no text was highlighted, as expected (last search term did not result in items to be shown)

Using ommand grouping (<..>) did not change this behaviour.

[void]

Thank you for testing and-search:/or-search: NotNull,

Query 1 is executed before query 2. (I suspect some caching/ reusing list entries)

PART 3:
Shows no results at all

There's currently issues with the command injection used to execute the additional search.
I'll have a fix soon.

Is the sort:... mandatory when using or-search: / and-search: ?

The sort is not mandatory.
Searches are executed in left to right order.
The last sort used is the final sort.