multi-level tags/subtags

[xahodo]

Currently tags are static (no custom tags can be defined) and the live in the root of the tree.

Problem: there are some situations in which one might want to have so-called subtags. One example might be in a magic system, or a technology tree. Another might be a social structure. It would be helpful to further organize items further.

In the project tree the root item could be a simple root item, below which things occur as normal, but a special item could be made that serves as a deeper level root item. Then when referencing tags in the deeper level, a / could be used

some examples of this:
Project root
Magic (root item, referenced by @Magic
Black (subtree, referenced by @Magic/Black
White (subtree, referenced by @Magic/White

Another example could be:
Project root
Characters (root item, refenced as normal).
Chinese 1 (subtree, referenced by @Characters/Chinese
Spanish 2 (subtree, referenced by @Characters/Spanish

Of course, with each example I only used two examples. This system tends to shine when there is enough to reference. The depth could be up to the user, to allow for even further subdivision.

---

Alternative solution:

Another option would be to allow "grouptags" with each note. Then a tag (say @Character could reference a "grouptag"). I guess an example of this would be:

In the project note it would look something like this:

@tag: Sandra
@grouptag: Dutch

Then in the scene file it could look like this:

@char: Dutch/Sandra

However, this solution is suboptimal, as it doesn't help with overview.

[vkbo]

But you can achieve all of this by just prefixing your tags and creating subfolders in the root folders. I don't really want to over-engineer this.

I am planning to add display names to tags, so you can choose how they are displayed on the GUI as opposed to how they are references. This ties into the feature request of being able to insert certain tags into titles and such as well, see #1468.

In the next release, 2.2, tags and references become case-insensitive. The "display name" value has already been added to the index, but defaults to how you typed it in the @tag: entry, and the value itself is saved as lower case. I plan to add a @display: or something similar, keyword to override this.

This will allow you to do something like:

@tag: Spanish_Maria
@display: Maria

[vkbo]

However, this solution is suboptimal, as it doesn't help with overview.

I see the point with this though. I think a better solution, that avoids the over-engineering issue, is to allow for a formalised way of subdividing the tags themselves. Say like you suggest with slashes, and then make it possible to split them in an overview.

There is a feature request to be able to export the meta data, #1507, which could have an option to subdivide tags based on an optional character, say _ or /, or whatever you want to use.

At some point I also want to add a way to display meta data in a more visual form than tables. This could also take such subgrouping into account.

The benefit of doing it this way is that we move the customisation to a narrow part of the code where processing time matters less (exports and rebuild options). Making the current system, including the index, fully flexible will likely cause performance issues. Parsing user input and checking it for consistency is always complex and you generally want to avoid it in as many places as you can.

[tmarplatt]

Suggestion: tag subdivision can be formalised simply by inferring from the same folder structure you mentioned, using the slash subdivider.

Say your Locations root has:

Earth
    Rome
Mercury
    Rome

Now you can reference the otherwise ambiguous Rome tag in your document with @tag: Mercury/Rome

[vkbo]

Yes, the tag system doesn't require single word. It splits the list based on the comma only, so using slashes in them is perfectly fine.

[vkbo]

I think I'm going to close this issue. I really don't want to add this level of complexity to the tag system. It is a parsing nightmare for the index class as well, because it introduces user defined data into the logic on the keyword side of things.

The tags system was never intended to be used in such a volume that it should require this in the first place. You can also achieve the desired effect by using prefixes as mentioned. Myself, I define a @plot tag for all the main events in my three act stories for the "Main" plot, and I prefix them all with "M.", which solves the issue pretty well.

The new reference panel under the document viewer also shows each category of tags in a separate tab, making it easier to locate them.

Once I get around to writing code to generate visualisations of the meta data, we could look at separating them by root folder. In such a setup, you could create two root folders for characters named for instance "Chinese Characters" and "Spanish Characters" to use your own example. The tag system will ignore the distinction, but a visualisation doesn't have to.