obsidian-linter: Bug: Linter fails to recognize aliases containing commas

Describe the Bug

This is related to the fix for #509

The following YAML array contains two aliases:

aliases: Scott, "Scott, Jr."

Linter parses this into three aliases.

How to Reproduce

I have attached the data.json file.

See the example above.

Linter produces a multiline array of three aliases:

aliases:
  - Scott
  - '"Scott'
  - 'Jr."'

Expected Behavior

Linter should parse the tags array exactly how Obsidian parses the tags array.

The example should produce a multiline tags array with two tags. The double quotes should be eliminated, and the tag containing the commas should not be escaped with single quotes.

Expected output:

aliases:
  - Scott
  - Scott, Jr.

Device

Desktop
[?] Mobile

About this issue

Original URL
State: closed
Created 2 years ago
Comments: 16

Most upvoted comments

I have not forgotten about this. I just have not had time to sit down and actually determine what it would take to allow for the removing of those parentheses. Hopefully I will have time later this week.

pjkaufman on Dec 8, 2022

Gotcha. I will think on this and see if it makes sense and is feasible to remove the quotes for multi-line and other array formats. It just gets a little hard to tell when quotes should be removed without knowing the previous and new formats of the array.

pjkaufman on Dec 3, 2022

It looks like it plays well with the change. @ScottKillen , could you clarify why you would expect the Linter to automatically remove the double quotes from around Scott, Jr. when it goes to multi-line? I know that it no longer needs them, but removing escaping is actually not as straight forward as adding them and I am not sure the Linter removes escaping at this time.

pjkaufman on Dec 3, 2022

Here are a couple of things to keep in mind for this.

Obsidian recognizes the single-line example as valid YAML. As does https://jsonformatter.org/yaml-validator.

Linter’s job is to make sure that a file is properly formatted–so if Obsidian recognized two aliases before running Linter, it should recognize only two aliases after Linter is done. Linter is the source of the single-line array example (from my original multiline array) then, when I asked Linter to convert it back to a multi-line array, it could not parse its own emitted YAML properly.

Linter should be able to parse its own results.

While it would be nice if the Linter could parse its own output, the Linter does not posses a means to parse all valid forms of YAML for purposes they were not designed for. For example, Obsidian adds at least 3 kinds of new arrays that are not valid YAML arrays, but are still valid YAML strings:

comma separated single string
space separated single string
single-line array that is space delimited

The only two array formats that YAML recognizes are

single-line array
multiline array

That is what causes some of the problem as YAML parser packages are not designed to parse out the Obsidian based arrays and Obsidian provides something to do the parsing that is not usable for testing which means it can change with no way for devs to know ahead of time. This means that a custom parser has to be used to emulate how Obsidian does its parsing. This is where the more simplistic approach is used. That is what you are seeing with the unexpected output for array differences. It definitely can be improved.

TLDR; The YAML is being custom parsed which definitely can be improved. Custom parsing is used to recognize the new custom formats for YAML arrays that are not traditionally recognized by YAML parsers as arrays. I am happy to improve the parsing logic, but it will likely never work exactly like Obsidian does in all cases. It will just act like it in most cases.

pjkaufman on Dec 1, 2022