Consistency in the way values written in markdown headers are parsed. about marktheripper HOT 2 CLOSED

When #1 was implemented, a small modification was made to the parser to recognize the following types:

• If enclosed in quotes/double quotes, treat as string.
• If it is enclosed in parentheses ([]), parse each comma-separated element recursively.
• If it can be parsed as long, it is assumed to be of type long.
• If it can be parsed as double, it is assumed to be of type double.
• If it can be parsed as bool, it is assumed to be of type bool.
• If it can be parsed as DateTimeOffset, it is assumed to be of type DateTimeOffset.
• If it can be parsed as Uri, it is assumed to be of type Uri.
• Otherwise, it is assumed to be a string type.

Uri may be too much. Even if we keep the value as Uri internally, I don't think it can be used effectively (it seems to be OK as string).
If possible, I would like to reimplement this in LL(1). However, DateTimeOffset is complicated, so I think a compromise is needed somewhere.

from marktheripper.

In #2, The parser code was standardized to unify the way metadata is read from JSON and the way values are handled in markdown headers.

from marktheripper.