FR: Fix YAML keys with no space on lint ("key:val" instead of "key: val")

Is Your Feature Request Related to a Problem? Please Describe.

Assume you have the following frontmatter:

Name: Chapter 2 Races
Tags: Players-Handbook  Part-1-Creating-A-Character  Chapter-2-Races
alias:Chapter 2

Attempting to lint this will run into an error, because now the Tags is assumed to be multi-line (or so I understand it at least). This issue is encountered during the Yaml-Key-Sort-Rule:

plugin:obsidian-linter:68 [Obsidian Linter] Lint File Error in File '300 Personal/303 DND/00 Ressources/Books/5e PHB/3 Done/Part 1/Chapter 2 - Races/Chapter 2 Races.md':
Error "YAML Key Sort" encountered an error in the yaml:  can not read a block mapping entry; a multiline key may not be an implicit key (4:14)

 1 | Name: Chapter 2 Races
 2 | Tags: Players-Handbook  Part-1-Creating-A-Cha ...
 3 | alias:Chapter 2
 4 | creation date: 2022-08-28 21:36
------------------^
 5 | modification date: 2022-12-03 20:13
YAMLException: can not read a block mapping entry; a multiline key may not be an implicit key (4:14)

 1 | Name: Chapter 2 Races
 2 | Tags: Players-Handbook  Part-1-Creating-A-Cha ...
 3 | alias:Chapter 2
 4 | creation date: 2022-08-28 21:36
------------------^
 5 | modification date: 2022-12-03 20:13
    at el (plugin:obsidian-linter:18:944)
    at H (plugin:obsidian-linter:18:978)
    at qc (plugin:obsidian-linter:25:1955)
    at En (plugin:obsidian-linter:25:4870)
    at Wc (plugin:obsidian-linter:25:7247)
    at tl (plugin:obsidian-linter:26:258)
    at Gc (plugin:obsidian-linter:26:469)
    at Je (plugin:obsidian-linter:52:223)
    at fn.apply (plugin:obsidian-linter:1998:177)
    at fn.safeApply (plugin:obsidian-linter:68:1570)

Describe the Solution You’d Like

Add an option to insert a space after the : if there is none.

Please include an example where applicable:

Name: Chapter 2 Races
Tags: Players-Handbook  Part-1-Creating-A-Character  Chapter-2-Races
alias:Chapter 2

would change into

alias: Chapter 2
creation date: 2022-08-28 21:36
modification date: 2022-12-03 20:13
Name: Chapter 2 Races
Tags: Players-Handbook  Part-1-Creating-A-Character  Chapter-2-Races
alias: Chapter 2

instead of aborting.

Describe Alternatives You’ve Considered

/

Additional Context

/

[Gewerd-Strauss]

I just tend to avoid them and do not plan to support them if someone were to try some of those monstrosities.

In that case, wouldn’t it make sense to make the setting optional, tag a disclaimer on to it that it doesn’t support mode x y z and call it a day? Just thinking loudly here right now; with something like a linter this cannot be the first edgecase that are just not feasible for support.

So it seems we have the following possibilities, after a bit of reading:

---

- martin:
    name: Martin D'vloper
    job: Developer
    skills:
      - python
      - perl
      - pascal
- tabitha:
    name: Tabitha Bitumen
    job: Developer
    skills:
      - lisp
      - fortran
      - erlang
judas: {name: judas D'vloper, job: Developer, skill: Elite}
fruits: ['Apple', 'Orange', 'Strawberry', 'Mango']
normal: 42

---

I had a bit more thought on it since my last post.
Stuff like the dict and list under judas and fruits seem most painful to me. For the rest, I see a couple groundrules:

1. : can only break stuff if followed by a non-whitespace character. This means the first line of any dict (martin/tabitha) can be ignored, or alternatively you would check if there are non-whitespace in the line until you encounter the linefeed.
2. In Dict-entries (e.g. Matin D'vloper for name, Developer for job, Tabitha Bitumen), stuff can break if the space is missing. However, on each of these lines the first encountered (not escaped) set of : must signify the end of the keyname, and the beginning of the value field. Thus, any (nonescaped) : that follows would be part of the syntax, and once those end you can check if the next character is a space (valid) or not (invalid)
3. Condensed metadata fields - e.g. judas/fruits seem too much of a pain to consider.

That’s my first idea here so far, at least. I’ll think about it over night a bit, gonna go leep now.

[pjkaufman]

Valid scenarios include lists being nested in lists, dictionaries in dictionaries, lists in dictionaries, etc.