Open Gewerd-Strauss opened 1 year ago
pjkaufman
commented
1 year ago This is an interesting request. It looks feasible, I am just not sure how the Linter would know which values to add the space after since you can have colons in the values as well and the YAML parser does not work on the YAML you have described.
Gewerd-Strauss
commented
1 year ago Short question for my own understanding:
YAML-fields in obsidian must have the following characteristics:
: followed by at least one space-character*With that, we can identify if a line of the block is valid or not, because we can check if each line fulfills those two conditions. Or rather, for all lines in the block that match condition 1 must be tested if the first group of : encountered reading left → right is followed by a space, or not.
Which then should in principle be very simple.
As far as I am aware, these rules are true for all sorts of yaml-formatting.
As an overview, as far as I know this yaml is still valid:
creation date: 2022-10-06 14:26
creation plain date: Thursday 6th October 2022 14:26:49
cssclass: clean-embeds
date: 06.10.2022
dateISO: 2022-10-06
modification date: 2022-12-05 14:43
tags: BE18 people/redacted/Strauss-Gewerd
adad:::::::::::: still valid, if a bit excessive
Test:
- d
- e(take it with a grain of salt, I don't write JS or Typescript or any of those languages, but I would be extremely surprised if the tools necessary for this wouldn't exist. )
Or am I not aware of a rule?
*: not entirely sure, but I think so?
pjkaufman
commented
1 year ago Some of the reasoning is correct. One issue is that spacing before a key is perfectly valid, at least in some cases. So the following is perfectly valid:
test:
key1: value
key2: valueIn this case you can just ignore the starting whitespace and then check for the key value pair. The main problem will arise in a list of dictionaries:
key:
- key2: value
key3: value2
- otherListKey: value3If key2 does not have a space after it, it would be ignored and you would still get the invalid YAML error. This can be considered an edge case and it is not impossible to account for this case as well. The main problem is this is just account for the more basic valid formats of YAML. There are a lot more complex forms of YAML as well. I just tend to avoid them and do not plan to support them if someone were to try some of those monstrosities.
pjkaufman
commented
1 year ago Valid scenarios include lists being nested in lists, dictionaries in dictionaries, lists in dictionaries, etc.
Gewerd-Strauss
commented
1 year ago 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: 42I 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:
: 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.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)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.
Is Your Feature Request Related to a Problem? Please Describe.
Assume you have the following frontmatter:
Attempting to lint this will run into an error, because now the
Tagsis assumed to be multi-line (or so I understand it at least). This issue is encountered during theYaml-Key-Sort-Rule: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:
would change into
instead of aborting.
Describe Alternatives You've Considered
/
Additional Context
/