FR: Create an Option to choose the source of the YAML title

[julianmueller]

I use the obsidian plugin Front Matter Title to have clean filenames, but display them more descriptive inside obsidian. This plugin uses the frontmatter keyword title, which replaces the displayed filename. But my real filename stays the same. Then I have my first (and only) H1 the same as my title description.

Your plugin gives the option to overwite the titlekeyword by the filename or first heading. As this is (in my case) ambiguous, I'd really like to have an option, to choose like "what relaces what". Like:

filename -> title title -> filename first h1 -> title (my preferred) title -> h1 etc

Ideally, id like my H1 to overwrite the title, but leave the filename as it is. (Also to put the title name in doublequotes.)

I dont really know a good way to visualize this setting, as Linter already has alot of options. But im sure youll figure out something clever :)

As of for now (like everything, before a linter stepped into my life) I do it manually, which leaves the "risk" of ambiguous information between the two.

Thanks!

[pjkaufman]

I don't think I fully follow what is being asked here. It may just be my unfamiliarity with the rule specifically being referenced as I have not done much work with the yaml title rules.

If my understanding standing is correct, the title rule you are referring to is https://github.com/platers/obsidian-linter/blob/master/docs/rules.md#yaml-title. If that is the case, then it defaults the specified key's value to H1, but if the value for an H1 is not present, it uses the file name instead. I am not entirely sure if that satisfies your use case.

As for adding any kind of quotes around yaml keys, https://github.com/platers/obsidian-linter/blob/master/docs/rules.md#escape-yaml-special-characters should take care of any values that have a : , ' or " in them that have not already been escaped.

Does that provide a clearer understanding of what the rule for yaml-title does? Please do let us know if the above rules do not satisfy your use case. I will see about updating the documentation for yam-title to include the order in which it tries to get values.

[julianmueller]

Yes, thats the rule im refering to. And thanks for the clearification! It actually does exactly what I need. I just wasent sure from the Documentation.

The only thing left is, that my H1 heading have spaces etc, and I handled my frontmatter so that what is a string gets surrounded by "..." doublequotes. Ive read, that the YAML specs dont really need it, but I think it makes stuff more clear. Also when having special characters (eg commata) in the header, they are currently not escaped.

How the Linter currently does it:

---
title: my funny, cool title
---
# my funny, cool title

How I'd like it:

---
title: "my funny, cool title"
---
# my funny, cool title

As this is very subjective, is there a reason, the linter does not put it in quotes? Is there a chance, that this might get updated?

[pjkaufman]

Commas are not really special characters as they do not cause parsing issues or incorrect interpretation of yaml key value pairs if not escaped. As a result, escaping the yaml would not help you.

[pjkaufman]

@julianmueller , sorry about not responding sooner, but I added an option to force YAML key escaping for the escape Yaml special charactera which should allow you to put the desires quotes around the content of YAML keys you specify. Please let us know if this does not satisy your needs.

Here is the link to the setting info: https://github.com/platers/obsidian-linter/blob/master/docs/rules.md#escape-yaml-special-characters.

[julianmueller]

Thanks for adding the option! It does exactly what I wanted. But... now it interferes with the "Replacing by H1" rule. So as I save, the title yaml key gets replaced by the H1, and the previous escaping characters are deleted. Could you make, that the escaping rule takes place after the replacement with H1? Thanks!

[pjkaufman]

Escaping has to happen at the start or else other things will break, so it is not really feasible to make the escaping after pulling in values for other YAML rules.

[pjkaufman]

If you wanted to, you could put in an FR to move it to its own rule that could be run at the end of the rule execution @julianmueller .