FR: Add Ability for Determining which Tags to Automatically Remove from the Frontmatter

[Dexter-Wx]

• [x] I have verified that I am on the latest version of the Linter

Describe the Bug

After removing some tags from the document and formatting my document with this plugin, the tags in the YAML Front-matter do not match the tags in the document (the corresponding tags in the YAML Front-matter are not removed).

How to Reproduce

Steps to reproduce the behavior:

1. Create a new md file with some tags
2. Format this document with this plugin
3. Delete some tags
4. Format again
5. See error

Expected Behavior

The tags in the YAML Front-matter match the tags in the document, regardless of changes to the document.

Device

• [x] Desktop
• [x] Mobile

Additional Context

It would be nice if tags in the YAML front-matter could be automatically updated like YAML Timestamp.

[pjkaufman]

Hey @Dexter-Wx . Could you explain how this is a bug? The Linter does not remove values from the tag list in the YAML frontmatter if my understanding is correct.

[Dexter-Wx]

Yes, the Linter does not remove values from the tag list in the YAML frontmatter.

[pjkaufman]

Could you explain how that is a bug @Dexter-Wx ? Which rule says that it does that? I ask because all of the rules I remember just copy/move tags to the frontmatter. But they did not use the body of the note to determine which tags to remove.

But I could be thinking of the wrong rules here, so if you could point me to which rule should be doing this/says it does this, then I can properly address this. Thanks for understanding.

[Dexter-Wx]

Well, it seems I misunderstood the functionality of this plugin. But I can only delete the extra tags in frontmatter manually. If the number of tags is large, it should be a pain to compare the tags in frontmatter and body one by one. According to what you say, this is not a bug。I should submit it as a new feature.

[pjkaufman]

That is my understanding. You may submit a feature request. The Linter only runs (with a few rule exceptions) under certain conditions which do not allow the Linter to know when a user has made specific changes. Right now it is just run manually, on save, or when you change the note you are focused on. There is an exception that the YAML timestamp runs x seconds after the note was last edited.

[Dexter-Wx]

Yeah, I know how to trigger this plugin. I'll submit a feature request about delete extra tags in frontmatter.

[pjkaufman]

Gotcha. I just wanted to make it clear that if this setting is added the Linter currently has no idea which tags to keep and remove unless something is defined as the source of truth.

[Dexter-Wx]

Tags in yaml come from two sources: one is extracted from the body by a plugin like Linter. They may be located at different paragraphs in the document. Using these kind of tags makes it easy to retrieve different paragraphs. The other is manually added by the user in yaml. Using these kind of tags makes it easy to retrieve the document. These two types of tags are confused together, and when I need Linter removing redundant tags, it is impossible to determine which ones really need to be kept. Do I understand you correctly?

[pjkaufman]

That is how the Linter sees tags. If all tags come from the body, then it is possible to determine which to remove and which to keep, but otherwise the Linter would have no objective way to say that the tag needs to be removed without a user specifying one way or another.

[Dexter-Wx]

When users manually add tags in yaml, they can add a certain prefix (e.g. #doc-). When deleting, Linter will be able to distinguish between these two types of tags

[Dexter-Wx]

Maybe add a custom tags prefix to the plugin's settings to avoid some naming conflicts.

[pjkaufman]

That is one way to deal with this scenario, but I would want feedback from several people who use the Linter that that is what they want since it sounds like users would have to redo all of their tags, unless I am misunderstanding.

[Dexter-Wx]

You're right. This will affect a lot of people if this solution is taken. It's not a perfect solution.