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.
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.