YAML: Empty multi-line array gets formatted into ambiguous format after properties edit

[PKMian]

Steps to reproduce

1. foo:
     - val
   bar:
     - 
   

2. Add a second value to foo to cause Obsidian to format the front matter.
3. bar get 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 foo’s value, 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 as 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.

Environment

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

---

Additional information

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.

Thanks.

[WhiteNoise]

thanks, we’ll think about it

[liam]

If Obsidian were to format empty bar as 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).

If you assign a property type to “bar,” then it will keep that property type when switching in and out of “source” mode.

For simplicity, we avoid writing empty lists as frontmatter values and always prefer null.

[PKMian]

@liam

If you assign a property type to “bar,” then it will keep that property type when switching in and out of “source” mode.

This doesn’t appear to work. I have authors: set to List property type and as in the first post’s initial example, adding a value to foo: via the properties, formats bar:\n - to be bar:, not bar: []. Maybe we are speaking of different things: I’m only referring to the formatting which Obsidian does after a property edit, not formatting which takes when switching views (which I don’t think is a thing).

The problem overall is mostly a non-issue given you have the Linter plugin: If you add the same keys which have been given the List property type to the Linter plugin’s “Force key values to be multi-line arrays” value, linting the file will cause bar: to be reformatted as bar: []. If you don’t have the linter, then you are still left with the ambiguous bar: (no []) after adding a value to foo: in the example stated above.

It would however be ideal if the user wouldn’t need to maintain this “Force key values to be multi-line arrays” value manually and the linter could read the types of the properties, formatting List types by default, something which may be possible using Obsidian’s API, I don’t know.

@PKMian

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.

I’ve also discovered that typing a value within the square brackets of bar: [] and linting automatically reformats the key-value pair as bar:\n -, making leaving bar:\n - as bar:\n - less relevant.

[liam]

@PKMian

Maybe we are speaking of different things: I’m only referring to the formatting which Obsidian does after a property edit, not formatting which takes when switching views (which I don’t think is a thing).

Yes, I’m referring only to the properties UI, since your original comment was concerned that semantics are being lost. Setting a type will preserve it externally from the file, so even if the property is blank, you don’t have to worry about Obsidian forgetting that its a list property.