It is reasonable to account the (one) end-of-line of a text block's opening delimiter as part of its physical value, just as the opening quote of a quoted value would be accounted part of that physical value. By that reasoning, text blocks as table values do not inherently violate of the restriction against whitespace between colon and value. Nevertheless, that makes the language a bit trickier to parse correctly, and it introduces the possibility for strange behavior. For example:
Code: Select all
# valid:
_table1 {'key':
;value1
;}
# invalid:
_table2 {'key':
;value2
;}
Don't be confused if you can't see the difference: that's the point. In fact, the difference is just that in the second table there is a space character after the colon and before the opening newline/semicolon delimiter of the value. (Or at least that's the way I typed it; I think the forum software may be eating the trailing space.)
Also, inasmuch as it is a rather fine distinction to allow text blocks as table values by accounting the newline as part of the delimiter, I think it will be lost on many users why the following is not valid when the _table1 example is:
Code: Select all
# also invalid
_table3 {'key':
value3
}
Is not the newline between key and value there also a delimiter? We even call such values "whitespace-delimited" in the changes document (though that's not an entirely correct characterization; "bare" would be more accurate).
Bottom line: the syntax and grammar as I interpret them can be successfully parsed, but the details in this area are likely to surprise users. Although it is not necessary to change anything, we should consider allowing arbitrary whitespace (including comments) between the colon and value in table entries.