Got it. The @search tag is still activated as a normal tag upon clicking. That seems wrong. I forgot to put a title in front of it and then went to click and edit. Instead it filtered the view for @search tags. But of course, on the other hand it’s a quick way to see all of the filters.
What’s your recommendation? Place all filters at the head of the document?
I think I broke the syntax:
Overdue @search((@due <[d] today or @today) and not @done)
Adding to my list… should be possible eventually, but currently no ‘)’ is allowed.
I love the implementation so far. Is the syntax exactly the same as FT?
A little hard to test while a ) breaks it but I can eagerly await the update. 
In the meantime I think you can rewrite these searches (at least some) using except or union. So it could be rewritten as:
Overdue @search(@due <[d] today or @today except @done)
I “think” that’s right… just typing in browser, haven’t tested.
I am currently using a plugin for FT that parses natural language dates into ICU dates, and it’s a life-saver. I know you probably don’t want to get into the weeds with that stuff too much, Jesse.
However, is there any chance you could set TP to understand today as a date value? That way somthing like @start>today would make sense.
The implementation is close but has diverged in some details… which I unfortunately haven’t kept careful track of … but for instance FoldingText doesn’t know about the today keyword for [d] searches. Documentation coming… someday.
Oh my!! That exists already? d = today’s date?
Yes… 
To make it work you need to use the [d] modifier. So for example:
@due <[d] today
today evaluates to midnight of the current date… the very start of the day.
I love it!
Some generally useful filters:
Not Done @search(not @done)
Do Next Week @search(@due >[d] today and @due <[d] end of next week)
Overdue @search(@due <[d] today or @today except @done)
Available @search(@today or @start <[d] today)
Stuck @search(@deferred or @hold or @waiting and not @done)
All @search()
Filters @search(@search)@macdrifter I think if I want to keep tags regexable then I think my only solution here to to allow for a ) to be include in tag values is to use an escape sequence such has \). Seems messy, but not sure if I have any other options. Thoughts anyone?
I don’t know, but every time I see an escape sequence I think it was a bad design (flame bait). I totally get what you mean but then I question the original syntax. If that’s the case then would it help to switch the syntax to @search{(@deferred or @hold or @waiting) and not @done} using curly braces?
I think by using {} we are left in a similar situation plus have an additional case to explain.
To make things complete we would still need to add an escape sequence for including } in searches, plus we would have to describe and parse {} syntax in the first place. It seems (and probably is) less likely that people will want to include } in searches, but the underlying ugliness would still be there.
I think the “clean” syntax solution is to offer a completely new syntax like discussed earlier in the thread. The problem with that approach (once I started implementing it) is that it starts breaking the API assumptions. For example adding/removing tags would only work for some types of items and not others. Also switching from one item type to another became complex and lossy.
I think I’m going to go (until I change my mind anyway) with the escape \) solution. It’s not supper elegant, but it:
Means there’s finally a way to include ) characters in tag values no matter what you use case is.
No new syntax constructs are needed, TaskPaper remains projects, tasks, notes, and tags.
Everything remains regex parsable, so it’s possible to easily build valid TaskPaper syntax highlighters for other editors.
I’m sure needing to include the escapes it will trip some people up, but I think the number of people who will write their own searches that need parentheses is relatively small. And they will have realtime feedback as they type that what they’ve typed is not a tag if they forget to include the escape.
Makes sense, but the biggest argument against is that you can’t just take a search expression and paste it in as a saved filter. You’d need to then escape the parenthesis and remember that it’s only one of the two parens that are escaped.
I’m sure you don’t want to spend a ton of time on this one feature though. I do think requiring escaping makes me far less likely to use the more advanced filter syntax. It creates a break with the standard query syntax and creates complexity that serves no value to the human reading it.
It doesn’t seem like a terrific use of your time trying to come up with a regex compatible solution, though.
Maybe a bug. When viewing a saved search if I try to edit anything, the view switches back to all tasks and puts the cursor at the top of the document. Is there no editing while viewing a saved filter?
Edit: I’ve filtered by tag. I try to create a new task by placing cursor at the end of a task line and hit return. Filter is removed and cursor is moved to top of document. If I scroll down, there is a new blank line where I had typed return.
That looks like a new bug… was working at some point recently! But yeah I see the same problem.
That’s what I’m here for. I’ll keep trying to break stuff.
Also impressed that you can mix the new “today” syntax and node filters. This filter works as expected: First to Start Each Project @search(/*//@start <[d] today[0]). It displays only the first task within each project that has an @start tag before today. At least it seems to.
I am a recent convert to TaskPaper. I have been using org-mode in Emacs and also OmniFocus, but both system tend to become very complex. I like the flexibility of a plain text format, but in org-mode, the formatting syntax for drawers, properties etc. tend to get in the way of the actual information in the file, so that outside of Emacs the files are not exactly human-friendly.
TaskPaper looks to hit a sweet spot with regards to features and legibility. The saved searches are a great addition, and I look forward to having some documentation to play with the syntax. For now, I am standing on the shoulders of macdrifter, and I have blatantly stolen his filter definitions.