Pipe separator behavior changed?

[spinmonk]

First and foremost, a tremendous thank you for the continued development. Everything literally changed how I deal with my computer, from use of folders to file naming to quasi databasing via file names. It's revolutionary and none of the similar file searches are even close to second. Completely great.

In the older versions, I would often use compound search queries to get a list of results from several queries essentially on one screen. I pretty much wanted to find everything that had Tom and everything that Jerry all at once. In the past, I'd construct the query using the pipe ( | , symbol above the backslash) and it worked beautifully.

Code: Select all

Tom | Jerry

would give you everything that had both Tom and Jerry.

Code: Select all

Tom the cat.txt
Jerry the mouse.txt
Tom and Jerry.txt
Tom the cat and Jerry.txt
Tom and Jerry the mouse.txt
Tom the cat and Jerry the mouse.txt

You could even use

Code: Select all

Tom cat | Jerry mouse

and it would only exclude Tom and Jerry.txt because it lacked the combination of Tom and cat or Jerry and mouse. So the pipe in the other versions worked as a sort of "OR" for parallel searches.

However, in the current versions the pipe is doing very bizarre things and I don't even really understand what it is currently useful for. If I enter

Code: Select all

Tom | Jerry

it will work as expected, returning all results that have either word just as above, but if I add additional words on either side of the pipe it drops results from the other end of the pipe command.

If I enter

Code: Select all

Tom cat | Jerry

the it returns

Code: Select all

Tom the cat.txt
Tom and Jerry.txt
Tom the cat and Jerry.txt
Tom and Jerry the mouse.txt
Tom the cat and Jerry the mouse.txt

Jerry the mouse.txt is excluded but all other results are returned. Which is bizarre because Tom and Jerry.txt fails the first clause of both Tom and Cat but meets the second clause of Jerry. But then Jerry the mouse.txt is excluded even though it meets it. It's like it needs to have words from both clauses but not all words from the first clause. So it must have Tom but doesn't require cat.

But if I reverse it,

Code: Select all

cat Tom | Jerry

it treats Tom as though it were optional and returns only

Code: Select all

Tom the cat and Jerry the mouse.txt
Tom the cat and Jerry.txt
Tom the cat.txt

So the order of the search terms ends up being critical to getting any set of results even though in regular usage Tom cat and cat Tom return identical results.


The strangeness expands the more search terms you enter. If you use

Code: Select all

Tom cat | Jerry mouse

you get the same kind of reduced results list of

Code: Select all

Tom and Jerry the mouse.txt
Tom the cat and Jerry the mouse,txt

But if you change the search to be

Code: Select all

Tom cat the | Jerry mouse

you get only

Code: Select all

Tom the cat and Jerry the mouse.txt

even though the previous two results both had a the in them already.

But if you change the search to be

Code: Select all

Tom the cat | Jerry mouse

you get back to the two results

Code: Select all

Tom and Jerry the mouse.txt
Tom the cat and Jerry the mouse.txt

all because you include the before cat


Is this intended right or some sort of bug? I'm trying to figure out how to put it into practice but it seems like the effects are really unpredictable.

For reference, all of the toggle options available from the menu bar are unchecked, included Enable Regex. I'm pretty positive I didn't use Regex in older versions of Everything. I would really love it if this is something I can fix by choosing some options toggle or something because the old pipe behavior was pretty integral for me.

Thanks!

[void]

In the alpha (version 1.2) or later, Everything gives the OR operator higher precedence than the AND operator.

Tom cat | Jerry
becomes:
Tom AND (cat OR Jerry)

To change precedence please use < and >
for example:
<tom cat> | Jerry
<Tom cat> | <Jerry mouse>

I have changed OR to lower precedence than AND for the next release.
This is the most common order of precedence.

Thanks for the post.

[spinmonk]

Excellent, that makes sense. I can work with < > in the meantime pretty easily.

It's interesting the way you described it that I can see how useful it could be. For example, I've taken to tagging filenames with '1, '2, '3, and '4 to represent different things so in the past if I wanted to find everything with Tom that was either at '3 or a '4 but excluded everything else, I would have done:
Tom cat '3 | Tom cat '4

But with the current alpha it is a lot simpler because it's just:
Tom cat '3 | '4

I can definitely see how it's helpful now that I can understand the syntax. Will there be a non-regex method of doing several OR criteria matched with an AND when the precedence is changed back? It's like now that I know it seems pretty valuable to have in my toolbox.

Thanks again

[void]

Will there be a non-regex method of doing several OR criteria matched with an AND when the precedence is changed back?

< > Parentheses will stay the same, for example find somefile.txt on c:, f: OR z: drive:

Code: Select all

<c:|f:|z:> somefile.txt