torque
4c966ca9d0
Once again I have entangled two conceptually distinct changes into a
single commit because demuxing them from the diff is too much work.
Alas. Let's break it down.
The simpler part of this change is to reintroduce "space strings" with
a slightly fresh coat of paint. We now have 3 different types of
string leaders that can be used together. So we now have:
| directly concatenates this line with the previous line
> prepends an LF character before concatenation
+ (NEW) prepends a single space character before concatenation
The `+` leader enables more æsthetic soft line wrapping than `|`
because it doesn't require the use of leading or trailing the
whitespace to separate words, as long as lines are broken at word
boundaries. Perhaps this is not as common a usecase as I am making it,
but I do like to hard wrap paragraphs in documents, so if anything,
it's a feature for me.
As I was considering what character to use for this leader, I realized
that I wanted to be able to support numeric map keys, a la:
-1: negative one
0: zero
+1: positive one
But previously this would not parse correctly, as the tokenizer would
find `-` and expect it to be followed by a space to indicate a list
item (and the additional string leader would cause the same problem
with `+`). I wanted to support this use case, so the parser was
changed to take a second pass on lines starting with the string
leaders (`|`, `+`, and `>`) and the list item leader (`-`) if the
leader has a non-space character following it. Note that this does not
apply to the comment leader (`#` not followed by a space or a newline
is a tokenization error) or to the inline list/map leaders(since those
do not respect internal whitespace, there is no way to treat them
unambiguously).
To reduce the likelihood of confusing documents, scalars are no longer
allowed to occupy their own line (the exception to this is if the
document consists only of a scalar value). Inline lists and maps can
still occupy their own line, though I am considering changing this as
well to force them to truly be inline. I think this change makes
sense, as scalars are generally intended to be represent an unbroken
single item serialization of some non-string value. In other words,
# these two lines used to parse the same way
key: 9001
# but now the following line is a parse error due to the scalar
# occupying its own line
key:
9001
# also, this still works, but it may be changed to be an error in
# the future
key:
[ 9, 0, 0, 1 ]
Inline maps have also been changed so that their keys can start with the
now-unforbidden string leaders and list item leader characters.