Bug: YAML from share as gist plugin invalid...

[olearydj]

Describe the Bug

The YAML generated by the "share as a gist" plugin (https://github.com/timrogers/obsidian-share-as-gist) is flagged as invalid by Linter. I'm no YAML expert, but it seems ok to me?

gists:
  - id: 4d06d592f0b0ae1771c0012de3562d8d
    url: 'https://gist.github.com/4d06d592f0b0ae1771c0012de3562d8d'
    createdAt: '2022-11-01T16:07:48Z'
    updatedAt: '2022-11-01T16:35:11Z'
    filename: Stochastic P1.md
    isPublic: true

How to Reproduce

Install the plugin, create the github key, share an obsidian page as a gist. YAML header is automatically generated to hold the resulting metadata.

When Linting the file with the above YAML, the following error message is put to the console:

Lint File Error in File ...:
YAMLException: bad indentation of a sequence entry (3:5)

 1 | gists:
 2 |   - "id: 4d06d592f0b0ae1771c0012de35 ...
 3 |     url: 'https://gist.github.com/4d ...
---------^
 4 |     createdAt: '2022-11-01T16:07:48Z'
 5 |     updatedAt: '2022-11-01T16:35:11Z'
    at du (plugin:obsidian-linter:18:944)
    at q (plugin:obsidian-linter:18:978)
    at Ul (plugin:obsidian-linter:25:696)
    at Kn (plugin:obsidian-linter:25:4861)
    at md (plugin:obsidian-linter:25:2150)
    at Kn (plugin:obsidian-linter:25:4870)
    at gd (plugin:obsidian-linter:25:7247)
    at hu (plugin:obsidian-linter:26:258)
    at bd (plugin:obsidian-linter:26:469)
    at ot (plugin:obsidian-linter:48:223)

Expected Behavior

Should not flag as bad YAML?

Screenshots

Device

• [x] Desktop
• [ ] Mobile

Additional Context

If it is a problem with the gist plugin please share details so I can communicate that back to him.

[pjkaufman]

I am not sure this is something that can be fixed directly as the YAML parser is an external package. It could be that the format provided is a newer format than is supported.

[pjkaufman]

If this format is valid, which it seems to be, it would be an upstream issue rather than an issue created by the Linter.

[pjkaufman]

I will have to see if this is operator error on my end or if the issue is actually a bug in the dependency.

[pjkaufman]

Thanks for reporting this!

[olearydj]

My pleasure. Let me know if you need anything more. I also shared the link of this report with the author of share as gist, as an FYI.

[olearydj]

Oh, neat - that crosspost shows up in the chain above.

[timrogers]

This doesn't seem to be a fundamental issue with the YAML parser, as it works for me in a REPL: https://replit.com/join/vhuytqxdzd-timrogers4

[pjkaufman]

This doesn't seem to be a fundamental issue with the YAML parser, as it works for me in a REPL: https://replit.com/join/vhuytqxdzd-timrogers4

Looks like I cannot see the replit without an account.

[timrogers]

Nothing too exciting in there - I just pasted the YAML into a string and then passed it to load and it worked.

[pjkaufman]

Interesting. I will have to see what is different about the YAML. @olearydj , did you provide your entire YAML block for the file?

It could be caused by another YAML key value pair.

[olearydj]

Yes. The YAML in my bug report is the entire block.

[pjkaufman]

Ok. I see the problem. The issue is the format make it act as though the value is a YAML array which triggers the escaping of the the id which is what cause the remaining problem. Let me see what I can do about that.

[pjkaufman]

I am not sure how to proceed with fixing this issue. The logic is correctly identifying the value as an array. However, it has no concept of what an array with an object inside of it is. The problem is being able to distinguish them since it is not using a parser to do so since that would cause a an error if there was a need to escape a value.

[pjkaufman]

For now, I would recommend disabling the escape yaml characters rule for any files that have this issue while I try to think of a good way to actually avoid this issue as the Linter is not designed to work on more advanced YAML data nesting when it comes to escaping characters.

[olearydj]

Ok, thank you for looking into it and for suggesting this workaround.

[pjkaufman]

I am working on a fix for this, but we will see how well it does. It essentially will try to account for dictionaries inside of multiline arrays by checking if the next line has a value that has the same amount of spaces preceding its value as the line with the dash (this is because escape comparisons are done one line at a time rather than accounting for all formats and parsing them and then trying to account for the difference). The main potential problem is using inconsistent spacing which could cause an issue. But I guess that is the price to pay to try to escape these characters.

[pjkaufman]

I should have a fix for this coming up. It should also account for this in Format YAML arrays as well.

[pjkaufman]

This should be fixed on master and in the next release. If it is not, please let us know. Thanks for helping make the Linter more robust.