foo: - val bar: -
- Add a second value to
footo cause Obsidian to format the front matter.
barget converted from a multi-line array into an ambiguous blank format, i.e.
bar:, when at the very least it should be
bar: (as when removing the final value of an array, see below).
Did you follow the troubleshooting guide? Y
Given the YAML example above, if instead you remove
bar will experience the same as noted above, but
foo, another multi-line array, results in the single-line array format
foo: , and not the ambiguous
foo: (easily mistaken as another data type, e.g. string, when looking at the YAML).
Having read Properties: preserve `tags: [ foo, bar ]` instead of converting to list? - #11 by WhiteNoise, I realise that maintaining YAML’s formatting isn’t a priority, only its semantics (which is unfortunate, but a YAML linter can largely re-reformat it back). However, it’s arguable that semantics are being lost when a multi-line array is displayed as
x:  in one case, and
y: in another.
If Obsidian were to format empty
bar:  in the YAML example, it’d communicate that it’s an array, and also provide the starting point to populate it with values (if editing the source). In my ideal case,
bar would be left as
bar:\n - because it’s more convenient to just click and add multiple values this way.
SYSTEM INFO: Obsidian version: v1.4.16 Installer version: v1.4.16 Operating system: Windows 10 Pro 10.0.22621 Login status: not logged in Insider build toggle: off Live preview: off Legacy editor: off Base theme: adapt to system Community theme: none Snippets enabled: 0 Restricted mode: on RECOMMENDATIONS: none
If I primarily used the properties to interact with the front matter, this wouldn’t be a problem, however, I edit in Source mode, and in that mode, the raw YAML is always displayed, not the properties representation, so I typically edit front matter directly. Maybe the upcoming additional improvements to properties will be enough to make Properties my primary method of front matter interaction.
Finally, in v1.4.14 multi-line arrays were not editable via Properties (displayed
[null]) and they weren’t being formatted after some other key had been edited (remained as
bar:\n -), so from my perspective, the v1.4.16 behaviour outlined in this bug report is a regression.