Problem with Quick Search query parsing

[jaywalker32]

Why does these two queries parse as the same, but only the second one returns any results?
Is it something to do with the HardParentheses option? How do I toggle it?

Code: Select all

Query:  :(name:*wallhaven*) /t/?
Parsed: name:"*wallhaven*"

Search: Quick Search
Mode: Boolean
SmartBooleanQueryParsing: Yes
HardParentheses: No
ExtendedPatternMatching: Yes
MasterInvert: Yes
Tags DB Only: No

Code: Select all

Query:  :name:*wallhaven* /t/?
Parsed: name:"*wallhaven*"

Search: Quick Search
Mode: Boolean
SmartBooleanQueryParsing: Yes
HardParentheses: No
ExtendedPatternMatching: Yes
MasterInvert: Yes
Tags DB Only: No

[jaywalker32]

Anyone have any idea on this?

I want to make a query with OR and AND for which I need to use brackets, but it seems brackets don't work in quicksearch.
What is the correct way to do it?

Eg:

works

Code: Select all

:tags:wallpaper OR name:*wallpaper* AND lbl:Red /t 

doesn't work

Code: Select all

:(tags:wallpaper OR name:*wallpaper*) AND lbl:Red /t

[admin]

Before I dive into this, is it still a problem?

[jaywalker32]

Yes, I just tried on the latest beta and it's still like that.
As soon as I add the brackets, it doesn't return any results (I removed the additional criteria to narrow down the issue):

Code: Select all

Query:  :tags:wallhaven OR name:*wallhaven* /t/?
Parsed: tags:"wallhaven" OR name:"*wallhaven*"

Search: Quick Search
Mode: Boolean
SmartBooleanQueryParsing: Yes
HardParentheses: No
ExtendedPatternMatching: Yes
MasterInvert: Yes
Tags DB Only: No

Code: Select all

Query:  :(tags:wallhaven OR name:*wallhaven*) /t/?
Parsed: tags:"wallhaven" OR name:"*wallhaven*"

Search: Quick Search
Mode: Boolean
SmartBooleanQueryParsing: Yes
HardParentheses: No
ExtendedPatternMatching: Yes
MasterInvert: Yes
Tags DB Only: No

[admin]

The parsed query seems to be identical in each case: tags:"wallhaven" OR name:"*wallhaven*" Is that correct?

[jaywalker32]

Yes. Identical.

I managed to quickly reproduce on my work pc as follows:

1. 2 files named: Project A.txt , Project B.txt
2. Tag first one with "pending"
3. Tag second one with "done"
4. F3 with :tags:pending or name:*Project* /t
5. F3 with :(tags:pending or name:*Project*) /t

Step 4 returns both files.
Step 5 returns no results.

[admin]

Yes, but the parsed name is NOT identical. In the second case you immediately see what's going wrong. The parentheses are seen as part of the strings:

Parsed: name:"*:(tags:pending*" OR name:"*project*)"


The problem you experienced is caused by the way parentheses are treated in the fast tag searches (DB lookup) triggered by the /t (and /T) switch. It all goes back to this change:

Code: Select all

v16.00.0251 - 2015-12-11 19:39
    ...
    * Tags Search: Parentheses in the unquoted search pattern were treated as 
      Boolean parentheses. Not useful in this context. From now on they are 
      treated as normal characters.
      A search like this:
        Free Jazz & Thoinot Arbeau (1520-1595) /T
      will find all items tagged "Free Jazz" AND "Thoinot Arbeau (1520-1595)".

There is no way around this. You cannot use parentheses in the way you intended AND use the /t switch.
Solution: Just remove the /t switch.

[jaywalker32]

I see.

But why was it decided that it is "not useful in this context" originally? Brackets are pretty essential in boolean search patterns if you want to combine OR and AND eg: (A OR B) AND C

Can't the literal brackets be escaped while leaving the bracket functionality as it was previously?

Unfortunately, removing the /t is not feasible in my case, since I am doing the search on [This PC] and searching via name: takes too long for quick searches.

I am currently just doing the search once and saving it as a paper folder, sort of as a cache.

Also, it seems the /? switch is giving the wrong output in this case, since it shows the two queries parsed identically. That's what confused me initially.

eg: :(tags:pending and lbl:green) and name:"test" /t/?

[admin]

1. I agree. I think parentheses in tags a rather a rare thing, and in case you use them and want to search for them IMO it feels pretty natural to quote (= wrap in double quotes) the pattern to escape them, or to escape them individually with \. So this is what I'm gonna do. So in the next beta your pattern will just work. You don't have to change anything.

2. You made a syntax error there. It should have been:
:(tags:pending and lbl:green) and name:"test" /t?

[jaywalker32]

Tested and it works perfectly now.

Thank you! This makes it so much easier now!