I do see in
"Everything 1.5 Alpha" , "Search Modifiers" (viewtopic.php?t=10906)
"< > = Group search terms
This does give identical results.
Glad I found this. Got very accustomed to using round brackets (as we do in Google searches) with this ON. Now that I am using 1,5 to get video/audio media length column listing, I was going crazy trying to figure out how to get grouping. I use it alot when I can't recall the exact string in filename to give me a good baseline to find things I only vaguely recall the exact file names of.
It would be good for consistency once it is released when using prior version options during update. Otherwise users may be very confused as was I.
Also good for consistency with Google search protocol.
Finally, if it's not brought back and migrated, replaying searches from History list will work totally different if there is a round bracket involved.
P.S. - THANK YOU for all you do! I haven't made a donation in a while and just re-upped in extreme gratitude for this VERY useful and complete ultra-functional one-of-a-kind tool. I would be lost without it!
Bring back "Allow round bracket grouping" in Options, Search pane
-
- Posts: 43
- Joined: Wed Apr 08, 2015 10:00 pm
Re: Bring back "Allow round bracket grouping" in Options, Search pane
IIRC, this setting was left out as its use was ambiguous and could give incorrect results: round brackets can be part of filenames too.
<> on the other hand can not be part of a filename.
The setting is still available. Not in the Options GUI (including the Advanced settings), but by directly editing the ini file (when Everything is not running), as Its use is discouraged.
@void: something for Everything 1.4 feature changes in Everything 1.5 ?
<> on the other hand can not be part of a filename.
The setting is still available. Not in the Options GUI (including the Advanced settings), but by directly editing the ini file (when Everything is not running), as Its use is discouraged.
allow_round_bracket_parenthesis2=1
@void: something for Everything 1.4 feature changes in Everything 1.5 ?
Re: Bring back "Allow round bracket grouping" in Options, Search pane
Thanks NotNull,
I have added search option changes to the feature changes list.
The allow_round_bracket_parenthesis setting is no longer supported as it causes trouble with regex and valid filenames.
I will consider re-adding a variation of this option, one that doesn't affect regex.
Maybe requiring spaces around the brackets..
Thank you for your support!
I have added search option changes to the feature changes list.
The allow_round_bracket_parenthesis setting is no longer supported as it causes trouble with regex and valid filenames.
I will consider re-adding a variation of this option, one that doesn't affect regex.
Maybe requiring spaces around the brackets..
Thank you for your support!
Re: Bring back "Allow round bracket grouping" in Options, Search pane
(So for some time now, I've been meaning to get around to posting about,Maybe requiring spaces around the brackets..
& yesterday when this thread popped, I thought I ought to get around to
posting about... So... let me find what I noted some time back...
Just going to post it as it was written.)
Code: Select all
<regex:red/\d\d|blue01 ->
i had /something/ like above
& i was not getting any red hits, only blue?
(red/ is meant to mean a directory path/path-part ending in "red" [DOESN'T MATTER])
[more correctly; i have, regex:<red\d\d OR blue01> AND -]
<regex:red/\d\d | blue01 ->
i put spaces in there
& with that i had both red & blue
[more correctly; i have, regex:red\d\d OR <blue01 AND ->]
SO... <WHITESPACE> "BREAKS" THE regex: & ANY OTHER SEARCH TERMS
ARE TREATED AS *AND*
and if there is a | without whitepace (surrounding it)
any other search terms are *AND*'d to *EACH* of the regex:
|'d parts
so: regex:red|blue 999 is the same as
999 regex:red | 999 regex:blue
so: red 999 is a hit
red is NOT
99 red is NOT
blue 999 is a hit
blue 999 red is a hit
9 blue is NOT
so: regex:red | blue 999 is the same as
regex:red OR <blue AND 999>
so: all the above red's are hits (incl. "blue 999 red"),
& the 2 "blue 999s" are hits
- but NOT "9 blue"
AH, SO /THAT/ is what the DEAL is !!!
(& in my results, below, while red/04 is a hit, in the case where
there is no whitespace around the |, the - was also being looked
for; so, red/04 *AND* -, & red/04 has no -, so THAT is why results
were not returned - AH !
Code: Select all
04 (with a path ending in ...red/, so c:/out123456/red/04)
08 (with a path ending in ...red/ ...)
12 (with a path ending in ...red/ ...)
blue01 - 12
blue01 - 14
blue01 - vi
Code: Select all
<regex:red/\d\d|blue01->
or
<regex:red/\d\d|blue01>
without the <sp> in there ([01-] vs [01 -]), or without the final -,
i (also) do get the reds (& blues) [BUT, THEY ARE *DIFFERENT* BLUES ?]
did i need an ESC somewhere?
or ?
red\ or red\\ or red\\\ also made no difference
outside of the <grouping> also made no difference
blue01\s- & blue01.- does get things working [POSSIBLY DIFFERENTLY]
so when i | in the context of the regex:
regex: is interpreting a non-whitepace |
as part of the regex:
(as part of a singular search)
where the whitepace breaks the search
into a regex: OR a <simple search> (assuming it's simple)
OK
so then why if there is no whitespace, what is the lone - causing to happen?
OH!
the very same happens
or does it?
i should be finding red/01 OR blue01 OR -
but i'm not?
so then, what "terminates" a regex: search term?
or, why does having a | in a "regex search term"
fail to find (a valid) first part when the
second part has a whitespace in there?
so...
| in a regex:
not surrounded by whitespace
causes the entire search term to be used as part of each part of the regex: search term
so:
regex:a|b
will find a OR b
123 regex:a|b
Re: Bring back "Allow round bracket grouping" in Options, Search pane
regex will eat |
For example:
regex:(a|b)
The | doesn't break the term.
The | is treated as a part of the regex term.
There's a couple other functions which also eat |
childfilelist:
filelist:
fullpathlist:
pathlist:
The following characters will break your term:
space
| (if the function doesn't want it)
> (if inside a < > group and the function doesn't want it)
Some functions will eat a starting > if they use > as an operator.
For example:
<size:>10mb>
size: will eat the >10mb term
The next alpha update will make Everything always eat the ( and ) in regex. Even when enabling allow_round_bracket_parenthesis2.
For example:
regex:(a|b)
The | doesn't break the term.
The | is treated as a part of the regex term.
There's a couple other functions which also eat |
childfilelist:
filelist:
fullpathlist:
pathlist:
The following characters will break your term:
space
| (if the function doesn't want it)
> (if inside a < > group and the function doesn't want it)
Some functions will eat a starting > if they use > as an operator.
For example:
<size:>10mb>
size: will eat the >10mb term
The next alpha update will make Everything always eat the ( and ) in regex. Even when enabling allow_round_bracket_parenthesis2.
Re: Bring back "Allow round bracket grouping" in Options, Search pane
Just making a note here:
A regex search in Everything 1.5.0.1372a will now eat ( and ) when enabling allow_round_bracket_parenthesis2.
A regex search in Everything 1.5.0.1372a will now eat ( and ) when enabling allow_round_bracket_parenthesis2.