Displaying 3 results from an estimated 3 matches for "kspam".
Did you mean:
spam
2018 Sep 29
2
xapian parser bug?
...as: subject:"not"
Interestingly, putting space around the operator seems to be a
workaround. Something about turning on phrase parsing maybe?
╰─% NOTMUCH_DEBUG_QUERY=y notmuch count 'subject:" not "'
Query string is:
subject:" not "
Exclude query is:
Query((((Kspam OR Kdeleted) OR Kmuted) OR Kbad-address))
Final query is:
Query(((Tmail AND 0 * XSUBJECTnot at 1) AND_NOT (((Kspam OR Kdeleted) OR Kmuted) OR Kbad-address)))
9927
2018 Sep 30
0
xapian parser bug?
...stingly, putting space around the operator seems to be a
> workaround. Something about turning on phrase parsing maybe?
>
> ╰─% NOTMUCH_DEBUG_QUERY=y notmuch count 'subject:" not "'
> Query string is:
> subject:" not "
> Exclude query is:
> Query((((Kspam OR Kdeleted) OR Kmuted) OR Kbad-address))
> Final query is:
> Query(((Tmail AND 0 * XSUBJECTnot at 1) AND_NOT (((Kspam OR Kdeleted) OR Kmuted) OR Kbad-address)))
> 9927
>
--
James Aylett
devfort.com — spacelog.org — tartarus.org/james/
2018 Sep 30
3
xapian parser bug?
...your output I believe you're not
> (the * in the query description I believe doesn't happen in those
> situations any more).
1.4.4 and later eliminate redundant 0 scaling factors, but this one
isn't actually redundant:
> > Query(((Tmail AND 0 * XSUBJECTnot at 1) AND_NOT (((Kspam OR Kdeleted) OR Kmuted) OR Kbad-address)))
If it was on the right-hand side of AND_NOT it would be eliminated
(because the right-hand side doesn't contribute any weight anyway).
FWIW, I also couldn't reproduce this (I tried with quest and 1.4.7):
$ quest -psubject:S -fdefault,boolean_any...