Skip to content

Conversation

@Goosse
Copy link

@Goosse Goosse commented Sep 3, 2021

In most cases, multiline values already worked (see here)except when a colon was intended to be part of the value in one of the following lines. This used to be interpreted as a new key/value pair.

With this change, all lines starting with 2 spaces will be interpreted as part of the value for the previous key, even if there is a colon in the line.

…y using two spaces on the following lines. In most cases, multiline values already worked except when a colon was intended to be part of the value in one of the following lines. This used to be interpreted as a new key/value pair.
@Goosse
Copy link
Author

Goosse commented Sep 4, 2021

As I've thought more about this. I'm not sure this is the best way to go about this. This would cause issues with in the following situation:

---
a: this is my very very very long string
  - a dash here would be interpreted as the end of the metadata
---

I might be more appropriate for use quotes around multiline strings like so:

---
a: "this is my very very very long string
- a dash here should not be interpreted as the end of the metadata
since it is inside the quotes."
---

And a note on the test linked to in the original pull request (testMergingOrphanMetadataValueIntoPreviousOne).
I think it should be altogether removed. If there is an orphan meta data value it should instead throw an error. An orphan value doesn't strike me as something intentional, and therefore should be caught in the build process. Quotes, on the other hand, would be something very intentional to mark a multiline value.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant