Yea. I understand. I just thought you might be interested since it is relevant. I totally support creating a specific new feature request of this concept. But I just keep forgetting to do it. The regex is helpful, but using the tag pane would be ideal.
The two tags are not equal to each other. The only similarity is that both names(or identities) contain the same text “John”.
And if one want to mention one of the two sub-tags without ambiguity, the only way to distinguish them is to provide the entire tag-name, including the parental tag name part and the sub-tag name part.
So “searching for sub-tag”, mentioned in the post 1 is ambiguous. And my interpretation is that it is actually “searching for the sub-tag name part within a sub-tag” and the sub-tag name part contains or is equal to “John”.
And a sub-tag name part within a sub-tag is not a valid tag.
So that the search should be accomplished by a “text” search rather than by a tag search.
I was using the tag: search, but you are right, the regex will work, albeit a text search, and therefore not cached like using the tag: search.
I’m not sure I understand your comment about ambiguity. In the case of this search, ambiguity is desired. I’m not looking for one specific thing, but a group that have a common attribute (sub-tag)
A query of this sort does answer a simple question, but maybe my use-case is unique?
For example, If the hierarchy were different (say recipe ingredients), one wanted to see all Recipes containing Cumin #Ingredient/Spice/Cumin then a simple search in the Recipe folder (or a #Recipe tag) combined with the sub-tag Cumin would answer that question.
In this case, the tag:#Recipe combined with regex /#Ingredients/[^\s]*Cumin/ would work also.
When you say:
Are you saying that nested tags are limited to a depth of 1 sub-tag, and not a hierarchy? This is not documented but only 1 level of nesting is shown in the examples, so that would change my thinking completely about using nested tags.
I mean that all three components within “#People/Doe/John” together compose the valid/unique name/identity of the tag “#People/Doe/John” and “#*John” is not a proper name/identity of a tag as “#*John” brings ambiguity. However, I think “#People” and “#People/Doe” are valid ones.
Your use case and requirement are valuable. And I personally think that making the tag search supporting regex would be convenient but it is not a necessity. And the reason is that I think in the case of that kind of search, when ambiguity is desired, one is actually looking for:
the tags whose tag name contains or is equal the text component provided;
the note content containing the tags which are identified in the 1st step.
And I think currently, the tag: search function is used for the 2nd step only and the entire search function provided in Obsidian is designed for searching note rather than managing / searching tag.
So I think the 1st step and the 2nd step are different issues. And combining them into one function is an advanced function, for convenience purpose, but it is not a necessity.