User customizable tags

[xahodo]

So, I have a requirement for a story to have a description of plants and what they do (so I don't mix them up when my characters start mixing them).

Now, NW doesn't allow for custom tags and, as was mentioned in a previous topic about this, it would close off the path for adding any new tags in the application itself.

So, I thought, why not remove all hard-coded tags and make the tagging system completely customizable? The application could provide sane defaults (like how they are currently) and an editing window could be provided to edit the tags and how they function in the grand scheme of things. F.e. attached root folder? Is it an alias for something else (such as the @mentions keyword) Does it show up in the menu to create new items? Are templates allowed? Maybe more? Does it show up in the outline view, and if so, where? Does it have potential further customizable attachments?

Both @ and % could be affected by this, allowing for increased flexibility. Of course, for both would be a different window/tab, as the % view does not have particularly many needs other than showing up in outline view?

I'm well aware this would be a large project, but it does open avenues to making more people happy and people don't have to convince the sole developer of the usefulness of a particular tag, as everything is customizable. Also, this eliminates the need for the @custom tag, as people could define what they need, so they don't need to keep track in their mind of what was stored under said tag. Better yet, the tag could be kept as part of the defaults.

The advantage of this approach is that it allows for customization, while also allowing for old projects to be kept as the defaults are still the same.

The only thing worrying me is the potential for performance impact. Currently, NovelWriter runs buttery smooth on even my toaster, and I would like it if it were kept that way. Would this be too much of a performance impact, or are there other problems which simply make this unfeasible, impractical, or even downright dangerous?

[vkbo]

So, I thought, why not remove all hard-coded tags and make the tagging system completely customizable? The application could provide sane defaults (like how they are currently) and an editing window could be provided to edit the tags and how they function in the grand scheme of things. F.e. attached root folder? Is it an alias for something else (such as the @mentions keyword) Does it show up in the menu to create new items? Are templates allowed? Maybe more? Does it show up in the outline view, and if so, where? Does it have potential further customizable attachments?

Making them free form would reduce functionality as well, or at the very least make default usage more complicated. That is not good. The @char, @pov and @focus references actually do have a meaning tied to its usage, and to retain those special use cases there would need to be configuration tools for all of this, which is exactly what novelWriter is trying to avoid.

Both @ and % could be affected by this, allowing for increased flexibility. Of course, for both would be a different window/tab, as the % view does not have particularly many needs other than showing up in outline view?

Customisable % lines is coming in #1784 and #1133. It still uses a standard part of the keyword, but allows subclassing those into new groups. I think that is a better model. It allows the app to still have some idea what they're for, and makes it possible to create custom tools for each kind. I plan to treat %Story and %Note very differently.

I'm well aware this would be a large project, but it does open avenues to making more people happy and people don't have to convince the sole developer of the usefulness of a particular tag, as everything is customizable.

I don't get the impression people in general are unhappy with it? I certainly don't get much requests for this.

Also, this eliminates the need for the @custom tag, as people could define what they need, so they don't need to keep track in their mind of what was stored under said tag. Better yet, the tag could be kept as part of the defaults.

The advantage of this approach is that it allows for customization, while also allowing for old projects to be kept as the defaults are still the same.

It also removes the default special treatment of the character-related tags, so this is not a net benefit. It would interrupt many people's workflows. It's hard to redesign core functionality in an application once its been adopted. novelWriter does have a principle of simplicity as a default. I'm fine with adding more complex features, as long as they don't get in the way when you don't want them. This will definitely get in the way.

An option is to extend the @custom logic instead. I would propose a new keyword structure though, to not disrupt those using @custom already. Maybe something like @ref.<category>: foo, bar where the <category> part is customisable like is planned for %Notes and %Story. That would not be as disruptive, and completely out of the way for people who don't need it

[xahodo]

An option is to extend the @custom logic instead. I would propose a new keyword structure though, to not disrupt those using @custom already. Maybe something like @ref.<category>: foo, bar where the part is customisable like is planned for %Notes and %Story. That would not be as disruptive, and completely out of the way for people who don't need it.

This sounds like a great idea! Would this mean users could add their own custom root folders, for example, for me, the "plants" root folder?

[vkbo]

I'm not sure what to do about root folders yet. I think the best solution there would be to keep the custom folders as-is and instead allow more customisation like selecting icon. The @ref.<category> keywords could be free-form in terms of which folders the notes are in.

I've been thinking of breaking the hard requirement of @char only pointing to tags in character folders. It does seem a little unnecessarily restrictive. Maybe some people just want their notes in a single notes folder, or separate them between volumes in a series in case there are multiple novels in a project.

The only use case for connecting root folder types to keywords is that it limits the list for auto-completion and allows for better prediction on where to auto-generate new notes from a new reference. But those can be solved in other ways, and are anyway minor.