Make tag:X/* include the parent tag in search results

Features
1

I've been using / in tag names as a lightweight convention for grouping related tags, and I noticed a small limitation in the current search behavior.

For example, suppose I have these independent tags:

browser
browser/foo
browser/foo/bar
browserbase

Currently:

tag:browser

matches browser itself.

And:

tag:browser/*

matches tags such as browser/foo and browser/foo/bar, but doesn't match browser itself.

I could use:

tag:browser*

but that is broader than intended, since it can also match tags such as browserbase.

My current workaround

At the moment, I work around this by explicitly adding a trailing / to tag names where the prefix could otherwise be ambiguous.

For example, instead of having:

browser
browser/foo
browserbase

I might use:

browser/
browser/foo
browserbase

so that searching with the / boundary avoids accidentally matching browserbase.

However, this doesn't feel like the right solution. It means some of my tags need to end in / while others don't, depending on whether their prefix happens to conflict with another tag. This makes tag naming inconsistent and exposes a search limitation in the tag names themselves.

Also, as far as Joplin is concerned, browser and browser/ are two different tags, so adding the trailing slash isn't merely a search convention — it changes the actual tag name.

Would it make sense for tag:X/* to include X itself?

In other words:

tag:X

would continue to mean exactly X, while:

tag:X/*

would mean X itself plus everything under the X/ prefix.

So:

tag:browser/*

would match:

browser
browser/foo
browser/foo/bar

but not:

browserbase

And the same rule could work at any depth:

tag:browser/foo/*

would include browser/foo itself as well as tags beginning with browser/foo/.

This would remove the need to modify the actual parent tag name just to make subtree searches unambiguous.

Not a request for hierarchical tags

I came across PR #2572 — Added hierarchical/nested tags, which previously implemented actual hierarchical/nested tags and was later reverted.

That's not quite what I'm suggesting here.

browser, browser/foo, etc. could remain completely independent flat tags. I'm only wondering whether / could act as a useful boundary for wildcard searches, with /* meaning "this tag and tags below this prefix".

That would give a fairly simple distinction:

tag:X      → exact tag only
tag:X/*    → X + tags under X/

For people who already use / as a naming convention, this would make it possible to search the whole group without the false matches that can result from tag:X*, and without having to add / to the actual parent tag name as a workaround.

There has also been some previous discussion around searching hierarchical tags, for example Synonymous tags, where tag:birds* was suggested as a possible way of searching a whole tag tree.

The Inline Tag Navigator plugin also implements a similar idea for inline tags: searching a parent tag can find its nested child tags.

Would this search behavior make sense in Joplin, even without formal hierarchical-tag support?

2

One more note: this can technically be worked around with:

any:1 tag:git tag:git/*

However, besides being unintuitive, any:1 turns the whole query into OR logic, so it's no longer possible to express:

(tag:git OR tag:git/*) AND <another condition>

This is another reason why having tag:git/* represent the whole group (git + git/*) would be useful.

3

That would be a breaking change unfortunately so it's unlikely we can add this

4

That makes sense. Perhaps this could be an opt-in search option instead, so the existing behavior remains unchanged?

The main goal is simply to have a way to include the exact parent tag when doing a wildcard tag search, while still being able to combine it with other conditions using AND logic.