Searching for a base tag in the Draft List using the tag:foo syntax, I would like any nested tags to also be included in the initial results.
For example:
I have three documents, each with a single tag: foo, foo/bar, and foo/baz.
If I search tag:foo, I will only get the first document. That seems incomplete—I would expect to get all three documents, as they share foo as the base tag.
(The current implementation of adding a slash to the query tag:foo/, returns only foo/bar and foo/baz, and that feels right as it’s drilling down the nesting.)
By that same token, it would make Workspaces easier because I need to add all those iterations of a nested tag in addition to the base tag in the filter.
I am fairly sure I understand the nuance of the request, but based on the follow up post, it made me wonder if you knew you could combine your queries with an OR?
tag:foo/ or tag:foo would return the drafts tagged foo, and and nested tags such as foo/bar and foo/baz.
Playing devil’s advocate to your expectations, that is also an exact match. Think about it from the flip side. What if you had only wanted to return drafts with a tagfoo, and not nested tags. This is also a logical syntax for that scenario then and the “tag + nested tags” set up is not what you would want and I think you could argue the same point around expectation.
It feels to me that there are multiple valid perspectives.
Unless I have also missed some filtering syntax somewhere, or Greg introduces a new shorthand syntax for it in the near term, I think the two part search combo might be a logical the way to go. At least for now.
1 Like
At the risk of opening the door to everything up to and including Regular Expressions 
… how about adding syntax for tag:foo/* ?
Absolutely, this can be bypassed with an OR. But that means tagging nested documents twice and I would question why have nesting at all.
[clipped recipe example, because it is fixed with @sylumer’s point on OR]
I also agree the lack of the forward slash is an exact match on the tag. I get why tags match the way they do—this is why my post is a feature request and not a bug report. And sure, others may want the functionality the way it is now—maybe the compromise is adding the slash keeps the base tag.
All that said, I still think the nesting syntax is missing the inclusivity of the base tag. One can hack around it but the functionality still feels off.
how about adding syntax for tag:foo/*
This is a good callout. In fact,tag:foo OR tag:foo/ works now, as @sylumer pointed out above, without the wildcard.
I don’t believe it does. If I have one draft tagged foo and one draft tagged foo/bar each has one tag only and each is matched by the filter. The behaviour you describe would be using an and in the filter rather than an or. I did test before I posted, so hopefully that is true - though I may have tested on the beta version of Drafts.
You suggested changing existing standard behaviour. I noted the logic beong valid in either case and hence applying a workaround and noting an alternative might be for new syntax.
The syntax I was thinking would be logical is the same as that posted by @DaveEmme. I don’t think it is confused with regular expressions given the delimiter format used for that and the fact that something similar is already used.
However, when it comes to implementing it, that would align to Greg’s underlying strategy around tags and filtering. I also know there is some work currently in the Drafts beta version that involves tags and filters, so that may have other implications as Greg builds out the functionality.
I would agree that there is an opportunity to include additional syntax, but I would not describe using a two part filter as a “hack” as it isn’t subverting the system in any way. New syntax would just be a shorthand for it.
Hopefully that adds a bit more clarity and context around my post above. Apologies for anything unclear from that first post.
1 Like
The shipping version of Drafts does not really support “nested” tags, per se. The / filtering was added as a convenience feature.
Nested tag support is a feature we are working on and plan to ship in this Fall’s major update, after the release of iOS 17 and macOS 14, so stay tuned.
2 Likes