OK, I got it - it would be the same behavior as can be found in zotero, for example.
There is no “silent death” of feature requests, I think. You can vote for it by giving it a like. Yet, there are hundreds of feature requests meanwhile; those with lots of support may be realized more probably at some point - though, from my experience, the developers only seldomly give feedback when - or if - concrete features might be implemented. There is an official obsidian roadmap, but it is often incomplete.
The only workaround I can think of at the moment would be to approach this behavior with a dataview query. This is certainly not exactly what you want, but with a corresponding query you would at least be able to get an approximate overview of the tags that are attached to files with a certain relationship to your active file. I don’t know if you have any dataview experience - if you are interested, I might try to fiddle with an appropriate query later…
Thanks for making the effort and responding. With ‘silent death’ I meant nothing more that that the thread had stopped. I could not work out whether the feature had been implemented or not; or whether meanwhile a plugin had become available providing this feature.
I am pretty new to Obsidian and I have no dataview experience whatsoever. I will have a look at it but from your description it might not be the thing that wins me over to Obsidian.
And if I wanted to I could continue adding other tags, but I don’t have any example files with that many other tags…
Some caveats with this approach:
You either need to use live-preview, or keep switching between reading and edit mode
If you add something partial to the tagFilter, and stop writing it’ll try to match that, and you might end up with an empty list until you complete the tag
As listed above the query requires nested tags to match completely, but you could alter that by changing to file.tags within the econtains() line. It also requires all tags to be matched. If you want a wider filter, you could change to any(matching) and get all files matching any of the tags listed in the tagFilter.
It could be possible to have this in all reading mode utilising another plugin like meta bind, but I’ve not done that here. Then that plugin would provide an input field where you could enter the tags, and store it in the frontmatter, before the query would pick up on the changes.
Does this get you any closer to what you wanted out of this?
If the feature request isn’t closed, it’s not dead. Posting in an old thread will bring it back to the top of the section list — but only post if you have something to contribute, don’t “bump” threads. You can press the heart to upvote.
Threads for implemented features (and sometimes rejected ones) normally get moved to the Feature Archive section, usually with a comment saying it’s been implemented (or rejected). Sometimes a comment is posted saying the feature will be implemented in an upcoming version.
Yes, this recreates the functionality that I am after.
The user interface is not so polished, unfortunately. It makes adequate for incidental use and I was hoping for more.
To sketch the background, I am currently using an application called KeepIt which has this feature nicely implemented. It is the tool I want to replace with Obsidian to be less dependent on third parties for my notes system.
I just posted a Templater thingy to keep selecting tags:
So now one possible question would be how to connect code like that into a query like the one above?! Sadly, I’m not sure how to do that, or if it would be better to use a plugin like the meta bind plugin for the multi-select, and then connect that together somehow with the query and maybe a refresh button/command which would update the tags to be selected from and the matching notes related to those tags.
In short, I do see the need for a better user interface to such a query, but I think it’s doable somehow using a combination of plugins.