Feature Request: List non-empty tags/subtags

[HifeFish]

Given a list of tags, I would like to have a quick way to see all tags that appear alongside that list. Right now, in ~/myfiles/store/tag1/ there are subfolders for all other existing tags, even those that never appear alongside tag1.

A possible solution could be another operator, e.g. & such that "ls ~/myfiles/store/tag1/&/" returns a list of those tags (and ~/myfiles/store/tag1/&/tag2/ is just identical to ~/myfiles/store/tag1/tag2/). For triple tags, the above would include namespaces associated to files in tag1 and "ls ~/myfiles/store/tag1/file:/format/eq/&/" would return all values of the file:format-tag that occur for files in tag1.

Example: I am in ~/mymusic/store/bandname/ and would like to see all albums by bandname. Even using triple tags, I only get a list of all albums and have to check if they are empty.

In general, I am missing a way to get an overview of the contents of a tag without looking at individual files.

P.S.: I tried to post about this on the forums, but https://www.tagsistant.net/kunena/index is giving me a "500 internal server error".

[Excerion]

I'd like to see this as well.

[StrumentiResistenti]

I see why this would be useful.

However, the introduction of the &/ operator would require a change in the query parser. A similar effect could be obtained using a "strict" version of the store/ dir (let's call it query/) that only lists available tags, given the query already provided. Would you consider this an equivalent solution?

I'm not rejecting the &/ operator you're suggesting; I'm just evaluating the pros and the cons of different designs. Even creating a query/ directory would require a rework in the parser that could even turn out to be harder to implement than the &/ operator itself.

[Excerion]

If you can cd into nonexistent directories inside a hypothetical query/ dir, then I don't see what advantages store/ offers over query/ and I'd use only that. It'd let me assign existing tags and create new tags, while still maintaining an overview. So with that feature, my preference goes to query/.

If that feature isn't possible, I'm undecided. So my first question would be whether or not it is.

[HifeFish]

The separate query/ directory would provide the folders I am looking for, just in a different place. The first difference that comes to my mind is that switching between both modes is quicker if you have the modifier at the end; both when modifying the path or browsing via command line or file browser. I can see both directions happening:

• You are looking for files using strict browsing (query/). Then you want to add a tag to that file, so you need to switch to store/.
• You are adding tags to files in store/tag1, but then want to remind yourself which tags there are usually associated to tag1-files, so you need to switch to query/tag1 for the list. Still, if it is easier to implement like that, I can work with the separate query/ directory.

@Excerion Having invisible directories in query/ is a good idea. The only downside I see is, that you will not have auto-completion for those invisible tags, so again, you might want a quick switch to the corresponding store/ directory.

[Excerion]

Actually, HiteFish's comment convinced me that an operator would be preferable. The thing is that I'd want to hide empty tag combinations most of the time. So to me it'd be ideal if the query/ behaviour was the default one, and there was an operator to have it behave like it currently does by default.

Also, perhaps I'm overlooking something, but wouldn't a quick fix be to have separate directories, and instead of a true operator, make it so that every directory contains a symlink that switches to the other directory? So ~/myfiles/query/a/b/& would link to ~/myfiles/store/a/b and ~/myfiles/store/x/y/& would link to ~/myfiles/query/x/y. Perhaps there might be some differences in behaviour compared to a true operator, but I think it'd satisfy for average use.

[zkol]

I do not know if this topic is active, but from my understanding could a query/ also be a way to get tagsistant usable with a graphical file manager (assuming that not closing @ is required to get results in this tree)