[FR] option to treat nested tag as normal tag ONLY when it has the same parent tag as the tag you're already browsing. would help reduce redundancy, explained better in issue

[afland]

This FR is a little hard to explain, so I'll try to do it with an example.

I organize my notes with e.g.

#topic/{topic1}
#topic/{topic2}
#type/{e.g. writing}
#status/{e.g. todo}

I chose this structure because it allows a note to have multiple topics, as opposed to a folder structure. The cross-references between different topics are really useful.

It's kind of awkward to navigate through the cross-references of different topics, though.

Let's say I have a note with #topic/calculus and #topic/electromagnetics

Right now, the navigation looks like this:

topic
     - > calculus
         topic
               - > electromagnetics
                   example note
         example note 

It would be nice if it instead looked like:

topic
     - > calculus
          - > electromagnetics
              example note
         example note 

In other words, when a nested tag (electromagnetics) has the same parent tag as the current nested tag that you're browsing (calculus), treat it like a normal tag. Getting rid of only the 1st parent tag (#topic) would be even better because sometimes I have double nested tags like #topic/config/vscode

[afland]

I know this probably wouldn't be helpful to most people, but it would be great for this plugin to have a lot of customizability with these more niche settings since everyone uses tags differently.

[afland]

Another alternative that's a little less niche:

Once you're in a nested tag, show all other cross-referenced nested tags with their full name instead of a nested structure, e.g.

topic
     - > calculus
          - > status/todo
              example note
          - > topic/electromagnetics
              example note
         example note 

[vrtmrz]

Thank you for informing me! Actually, if we enable Do not treat nested tags as dedicated levels, we will see the behaviour that you said. But, uniting with common parents would be useful in default too. I will check the possibility and why I did so.

[afland]

Thank you for informing me! Actually, if we enable Do not treat nested tags as dedicated levels, we will see the behaviour that you said. But, uniting with common parents would be useful in default too. I will check the possibility and why I did so.

It's a little different than what I was saying because I still think the top level hierarchy is useful. I was saying that any tag 1 level down or more (so the cross references, e.g. #topic/electromagnetics for

topic
     - > calculus

) would be shown with their full path rather than the nested structure to reduce clutter. To do that, I think it would be better if the Do not treat nested tags as dedicated levels option showed the full tag path instead of just the nested tag's name, and there could be a slider to customize how many levels deep that option should be activated

[afland]

but yeah I don't know whether that or an option to unite cross-referenced (meaning both are tagged in a note) nested tags with common parents like I described in the OP would be easier/better

[vrtmrz]

@afland Implemented on v0.12.0. Maybe there are minor changes from the specification we talked, but this will work even if there are tags in the intermediary level that are not relevant.

Could you check the behaviour?

Note: We still could not treat a tag which used as an independent tag and parents of nested tag at once. Like ‘#dev’ and ‘#dev/svelte’

[afland]

@afland Implemented on v0.12.0. Maybe there are minor changes from the specification we talked, but this will work even if there are tags in the intermediary level that are not relevant.

Could you check the behaviour?

Note: We still could not treat a tag which used as an independent tag and parents of nested tag at once. Like ‘#dev’ and ‘#dev/svelte’

Thanks for developing this so fast! seems like it works pretty good. Are you saying that if a note has #dev and #dev/svelte, that it'll only show up like

dev
     - > svelte
          example note

?

[vrtmrz]

You're welcome and thank you too! I'm very happy to hear that. It was behaving strangely when there were more than two such files, but it fixed. Would you kindly check the behaviour again?

[afland]

You're welcome and thank you too! I'm very happy to hear that. It was behaving strangely when there were more than two such files, but it fixed. Would you kindly check the behaviour again?

Works really well overall, but I found 1 issue. Not sure if it's reproducible.

I have a tag #topic/linux and a deeper nested tag, #topic/linux/KDE Right now, I have 2 notes with just #topic/linux and a few more with #topic/linux/KDE Both of the notes with #topic/linux also have #type/config The navigation only shows them like this:

topic
    - > linux
        - > KDE
        type
            - > config
            note 1
            note 2
        {here is where note 1 should also show}
        {here is where note 2 should also show}

When I remove the #type/config tag, it shows directly under #topic/linux like it's supposed to

[vrtmrz]

Finally, I was able to reproduce this! Thank you for your patient confirmation. TagFolder dynamically parses and creates the structure, so it was going wrong when there was a dedicated tree and a normal tree when dedicated tree has been made first. Fixed on v0.14.1. could you please try this again?

[afland]

Finally, I was able to reproduce this! Thank you for your patient confirmation. TagFolder dynamically parses and creates the structure, so it was going wrong when there was a dedicated tree and a normal tree when dedicated tree has been made first. Fixed on v0.14.1. could you please try this again?

When I expand #topic/linux, another topic/linux appears for 1-2 seconds:

[vrtmrz]

It will take a few seconds to be abridged. It depends on the number of tags that can be combined, so maybe we need a better algorithm for expanding and shrinking the hierarchy of tags. (Now we're doing it in the roundabouted way)

If the end result is as you imagine, I would like to improve on this next!

[vrtmrz]

@afland

When I expand #topic/linux, another topic/linux appears for 1-2 seconds:

I said this as if it were a specification, but I realised it was solved by the devices' muscles. Fixed misdesign of structuring and it looks like works better. I'm sorry to keep making you, but could you try once again?

[afland]

@afland

When I expand #topic/linux, another topic/linux appears for 1-2 seconds:

I said this as if it were a specification, but I realised it was solved by the devices' muscles. Fixed misdesign of structuring and it looks like works better. I'm sorry to keep making you, but could you try once again?

seems pretty good now. There are still some tags where the note only appears in the cross references.

Ex. I have a note with #topic/sci/physics and #status/todo, and this is how it looks: It only appears when I unfold #status/todo. I think it makes more sense for it to show under just #topic/sci/physics as well

[vrtmrz]

I really appreciate your efforts! I wonder why I didn't noticed that. As you said, we had failed structuring tags which as like below: It occurs in cases like this:

• The tag has child tags and more than two child documents.
• All child documents have the same combinations of tags.

Fixed on v0.14.4. I think this will finally work.

[afland]

I really appreciate your efforts! I wonder why I didn't noticed that. As you said, we had failed structuring tags which as like below: It occurs in cases like this:

• The tag has child tags and more than two child documents.
• All child documents have the same combinations of tags.

Fixed on v0.14.4. I think this will finally work.

It looks like this in the update now: merge redundant combinations, reduce duplicated parents in nested tags enabled hide items -> only intermediates of nested tags

[afland]

also, I have a bunch of notes with #topic/dev/html, and only 1 of those also has #type/MOC Only the #type/MOC note shows, none of the others do.

Also, those hidden #topic/dev/html notes are included in the count next do #topic/dev (35)

[vrtmrz]

Oh... I have to check the behaviour more deeply.

Could you please send the information of your vault by this snippet? The whole document's tag information will be copied into the clipboard when you run on the DevTools. (You can launch DevTools by pressing Ctrl+Shift+i or Command+Option+i)

copy(JSON.stringify(this.app.plugins.plugins["obsidian-tagfolder"].root.allDescendants.map(e=>e.tags)));

If you don't want to send tags' names, you can change names if they are not related to the issue. And you can use the next snippet for your convenience. (All tags will be encoded into numbers, please inform me which numbers are weird.)

let t = new Map(),c=0;copy(JSON.stringify(this.app.plugins.plugins["obsidian-tagfolder"].root.allDescendants.map(e=>e.tags).map(all=>all.map(e=>e.split("/").map(w=>t.get(w) ?? ( t.set(w,`${c++}`) , t.get(w))).join("/")))));

[vrtmrz]

Or, possibly works fine at v0.14.5. (We had a many bugs around this)