Open jedharris opened 4 years ago
This would clutter the design a bit. I'm not sure it's worth it. The annotations are very readable as is, if a little more verbose than counting the ornaments (decorations?) as annotations themselves.
For example, how would we parse the following?
-++ +A
Would we just remove the white space and say that the decoration is -+++
? Or do we have four separate decorations, i.e. -
, +
, +
, and +
? Or do we have two separate decorations, i.e. -
and +
?
These are questions that annotations neatly sidestep (with the possible exception of repeated keys—how do we handle that now?).
I think annotations data [foo: bar]
should be kept separate from ornaments + plusOrnament
** starsOrnament **
But I think the ornaments should be captured as part of the parsed AST, ornaments being matched leading/trailing pairs. And personally I would parse "list prefixes" as separately from attributes.
* single star header *
-> "ornament": "*"
(not currently captured)
* bullet point
-> "list_prefix": "*"
(not currently captured)
[ ] incomplete
-> "list_prefix": "[ ]"
(currently annotation)
[x] complete
-> "list_prefix": "[x]"
(currently annotation)
Each ornament ("leading & trailing dashes, colons, asterisks, chevrons, underscores") could be captured as annotations. E.g. [prefix: **] or whatever. This leaves the syntax just as flexible and uses existing entity types. It lets users of the format find out what ornaments were provided without parsing the raw data.
Semantic ornaments would be much easier. With Unicode the space of possibilities is large.
There's no need to reserve the "prefix" and "suffix" annotation types (or whatever terms are chosen); they can be used explicitly too if desired.
I'm inclined to think that whitespace should not be captured as ornament annotations but could maybe be convinced otherwise.