This all seems like a lot of churn to me. Legend already functionally enables hierarchial #tags, via the segmented naming technique described above. No, it doesn’t have a GUI to help manage, but it’s not really rocket science to stay on top of. And it is currently working already for most of us in this thread.
The central issue is whether #tags remain “compartmentalized” by document – a behavior inherent in the current doc structure that would be broken by the new backend. It sounds to me like everybody above would be happy if Legend just kept working like it already does: populate the auto-complete list only with #tags already in the current Document. That will really be a ‘root level node’ in the new backend but surely it isn’t hard to adjust Legend so it works that way? Is anybody saying they actually want a fully-populated auto-complete list with ALL tags in every “document”? I’m not seeing that ask anywhere.
A Tag Manager would be nice – but not for hierarchial tags – just for bulk edits of what we already have today. Things like changing all instances of #tagA to #tag_A. Or, deleting all instances of a single tag. Otherwise you can get stuck with a bad tag-scheme and the manual work required to revise it is crushing. I have been able to use drag/drop within Group-By Tag Panes to quickly reassign a single tag to multiple items, but that method has limitations.
And really if we’re keeping things simple and clean – all that’s needed is a (good) Find/Replace tool since tags are just text. It would need to accept <null> in the replace string, and support wildcards (so we can find text that’s only within tags such as “#*tag” to find “#example_tag”). And it needs to operate across multiple (or all) documents at once. But if it’s a Pane-level tool, and Panes will be able to point at multiple Documents in the future…that is already solved.
