I’m not quite sure what your goal is, but you can search based on tag values. For example:
@repeat mon
Will match @repeat(mon, tue, wed) while:
@repeat fri
Will not.
Just thought I’d chime in again to say I’m so glad you’re working on this, Jesse, and I can’t wait to see the final implementation.
I love the thought of searches being plain-text and so easily saveable.
Well now that I’ve started implementation all of my syntax ideas go out the window 
They all run into issues of one sort or another when I actually start the implementation. Instead I’m going for the simplest solution which is to embed the search in a tag. So from my above example searches will look like:
Do Next Week @search(@due >[d] today and @due <[d] end of next week)
Now I’m not sure why I felt the need to invent a new syntax. The above case “Do Next Week” would be displayed in the sidebar with some searchy icon next to it to distinguish from a normal project, and and when you select it the search will get applied.
No harm in that. I think it’s weird having tags within tags but it would work. Most TP based apps would simply display that line as a note so it shouldn’t be too distracting.
One comment about your implementation plans. I assume this will act like a filter. It would be good if clicking that filter somehow highlighted the filter tag in the document too. Makes editing it easier. It would be a pain to try to edit a filter name by first showing all and then searching for the filter by name.
Just posted a first version to try:
1 Like
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.
1 Like
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)
1 Like
@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.