Queries with more than two conditions in parentheses don't work
My "Start page" uses the query "today, tomorrow, overdue." I was overjoyed when you added the ability to filter by negated label (the some_condition & !@some_label syntax). But sadly, these two don't seem to work together, as:
(today, tomorrow, overdue) & !@work
doesn't do any filtering. Darn!
Note that it isn't just the negation; this doesn't work either:
(today, tomorrow, overdue) & @work
However, after a little playing around I noticed that this *does* work:
(today, tomorrow) & !@work
as does any combination of *two* items in the parentheses.
So, it appears that something about the way the parentheses are implemented limits the functionality to two items. Is this by design? If so, it seems like an odd (and unfortunate) choice.
Thanks so much for the expanded query syntax in general -- it's very useful and much appreciated. Removing this limitation would make it even more useful.
Please try this:
(od & !@work) | (tod & !@work) | (tom & !@work)
The (today, tomorrow, overdue) filter is "stretching" the boundaries of the "traditional" comma separation. The new syntax prefers the use of the "pipe" character - | as OR so combining the comma-separated dates with the new syntax may cause this problem.
Thanks for the tip!
Note that a more compact version of the same syntax works as well:
(od | tod | tom) & !@work
Just a followup on this for the record and in case anyone runs across the same oddity that I have.
I have only noticed this since the advent of the "New UI" in late January 2014. It may have been there all along, but I don't know.
I expected the following two filters to produce identical results, but they do not:
(od | tod | tom)
(tod | tom | od)
In the first case, results are organized as expected, with separate headings for Today, Tomorrow, and Overdue tasks, with the individual tasks in the correct places. In the second case, all tasks are under a single heading (Today).
This may be a bug or just an artifact of the filter syntax. If the behavior in the second case (with 'od' at the end of the list), I'd suggest some additional documentation is needed to make it clear the the order of the terms matters.
Thank you for letting us know. This is actually an issue caused by the overdue filter. It's a bit "special" and preferably should be used at the front. It should work fine elsewhere, but it seems to have an issue with |.
The fact that the placement matters is indeed true, if you want to see tasks for today at the top and then tasks due tomorrow, you search for "tod, tom", otherwise "tom, tod" will of course show them the other way around.
We will document it (or preferably adjust the od filter to not cause problems), but for now, it's adviced to use commas in cases like this especially when od is involved). So something like:
od, tod, tom
as well as
tod, tom, od
will work fine, but still - the results will of course be shown as you want them to show based on the order of the queried "elements".
Thanks for the insight . . . maybe a mention in the help for filtering that od should be placed at the beginning of the query would save others some time.
I use the OR syntax (od | tod | tom) because combining more than two items separated by commas doesn't work inside parentheses (as noted at the start of this thread). I like being able to quickly add an "@work" on to the end of my standard query (the one that comes up by default), which seems to require the parentheses to work correctly.
I like the updated UI, by the way . . . nicely done!
Well, not to keep harping on this issue, but the latest update of the iOS app seems to have made a regression in this area. Now, on iOS, the OR syntax in parentheses works differently than on the web site. Specifically, the filter I mentioned above:
(or | tod | tom)
returns no results on iOS, while behaving as expected on the web site and on the Android app.
Prior to the most recent app update, it seemed like the iOS app managed its own set of filters, so I hand one set up to return the results I wanted. Now, however, it appears that the web site and all the apps share the defined filters (which is good!), but they work differently on the iOS app.
Thank you for your report, I've been able to reproduce this issue and will pass it to the developers.