Is there a reason titles and identifiers for Markdown-based notes are quoted?

[grtcdr]

I noticed after switching to Markdown for my notes that Denote adds quotation marks to the value of the title and identifier fields. This is not the case for org and txt file types.

I found this odd given that most other YAML-based writing systems would not do such a thing. I'm not a YAML expert but there are very few cases where one should explicitly quote their strings, one such case is when the string starts with a special character.

identifier starts with a number and contains a non-digit character (T) so it will be interpreted as a string which means the quotes are unnecessary here.

title is very unlikely to begin with a special character that could break the parsing of the front matter, whether that be by Denote or some other tool. I could be wrong and there may very well be a technical reason that eludes me.

[protesilaos]

From: Aziz ***@***.***> Date: Mon, 14 Oct 2024 05:17:30 -0700 I noticed after switching to Markdown for my notes that Denote adds quotation marks to the value of the `title` field. This is not the case for `org` and `txt` file types. I found this odd given that most other YAML-based writing systems would not do such a thing. I'm not a YAML expert but there are very few cases where one should explicitly quote their strings, one such case is when the string starts with a special character. A title is very unlikely to begin with a special character that could break the parsing of the front matter, whether that be by Denote or some other tool. I could be wrong and there may very well be a technical reason that eludes me.

I have no good answer for this. I did it because on my Jekyll-based website the YAML front matter would always give me problems if it was not wrapped in quotes. I cannot remember what it was, but things like "it's" or a comma would make it not read the value correctly. This was years ago though and YAML might have improved in the meantime. Do you have any problem with the current setup? If so, we need to see how best to address it.

…

-- Protesilaos Stavrou https://protesilaos.com

[grtcdr]

Thanks for the clarification, Prot.

My problem is merely a nitpick, I have nothing against quotation marks, but would rather do without them when possible. If however my nitpick is common or seems worth digging into ¹ — and I would leave this assessment to the community and yourself, then I'd say the best course of action is to only install the quotes when there is a reason to do so.

We could implement a series of conditions that determine in the end whether the title is to be quoted or not. Your single quote example is a great one, that could break parsing, so it would be part of this condition set, we'd have to inspect the YAML spec for more of such conditions.

It is however unnecessary to quote the identifier, correct me if I'm wrong, but users shouldn't modify it and the identifier is, as it is currently stands, a correct string quoted or not.

Footnotes

1. I do not expect you to want to support this change because it seems too much like a personal annoyance with no technical side effect. ↩

[protesilaos]

From: Aziz ***@***.***> Date: Wed, 16 Oct 2024 02:24:06 -0700 Thanks for the clarification, Prot.

You are welcome!

My problem is merely a nitpick, I have nothing against quotation marks, but would rather do without them when possible. If however my nitpick is common or seems worth digging into — and I would leave this assessment to the community and yourself, then I'd say the best course of action is to only install the quotes when there is a reason to do so.

I have no strong opinion about this. Stylistically, I prefer it without quotes though my experience with YAML has been problematic in this regard. I do not know about TOML, by the way, so I am treating it with caution.

We could implement a series of conditions that determine in the end whether the title is to be quoted or not. Your single quote example is a great one, that could break parsing, so it would be part of this condition set, we'd have to inspect the YAML spec for more of such conditions.

Indeed! There probably are many more that will be due to user error, like an open parenthesis that is not closed. The question then is if we want to make it fool-proof or keep it as-is and let the advanced users modify the 'denote-file-types' to use a different function than 'denote-format-string-for-md-front-matter'? Alternatively, we can modify 'denote-format-string-for-md-front-matter' by adding all the requisite conditionality. I am okay whichever course of action we choose. To me what matters is that we do not break existing files that have the quotes.

It is however unnecessary to quote the identifier, correct me if I'm wrong, but users shouldn't modify it and the identifier is, as it is currently stands, a correct string quoted or not.

Indeed. This is just an artefact of how we handle the title, so we continue the same way.

Again, I do not expect you to want to support this change because it seems too much like a personal annoyance with no technical side effect.

The easy way out for us is to not change anything unless we have some case which shows how the current setup is problematic. Though I agree with the principle you are raising. * * * Unrelated to this, have you assigned copyright to the Free Software Foundation? You will need it to make more non-trivial changes to Denote (which you are welcome to do).

…

-- Protesilaos Stavrou https://protesilaos.com