Spec
jroper — 2014-09-03T21:57:25-04:00 — #1
There are many markdown extensions out there. I'm wondering if it's worth, as an appendix to the spec, for the authors of the spec to write a guide for choosing the syntax of extensions. This section could capture things that aren't in the spec like:
- Characters and/or constructs that should be considered reserved for a possible future addition to this spec
- Thoughts by the authors on what sort of syntax could be used to introduce new inline or block features
- Patterns for syntax extensions
For example, let's say someone wants to implement an extension that renders a table of contents. Would something like @toc@, or %toc%, work as a block element? Or is that likely to conflict with other known extensions or possible future additions to the spec?
Another example is an extension we use for the Play Framework documentation that pulls in code snippets from external files (so that the code snippets can be compiled/run/tested), it's a block element similar to the image syntax:
@[snippetlabel](path/to/code.scala)
This is a possible pattern that could be repeated for many different types of extensions that refer to external resources, and if the authors of the spec think this is a good pattern, of prefixing a link with a special character like this, then perhaps it's worth mentioning it.
sandmansandine — 2014-09-04T00:22:25-04:00 — #2
(post withdrawn by author, will be automatically deleted in 24 hours unless flagged)
dajare — 2014-09-04T03:01:03-04:00 — #3
I'm just connecting a couple dots here - but this topic seems to relate to the suggestion that it woud be worth discussing how best to include simple extensibility points for extensions.
As the core spec "settles", the extensions will remain of keen interest to many, I'm confident.
jroper — 2014-09-04T03:30:27-04:00 — #4
It certainly does, and I didn't notice that topic before.
I'm not sure whether this topic should be considered a duplicate of that, or whether it should be considered the fulfilment of Jeff's suggestion to:
create a topic about how best to include simple extensibility points for extensions, ways to namespace them and handle order so they don't conflict, etcetera.
dajare — 2014-09-04T03:53:56-04:00 — #5
The latter! The heading is clear, as is the focus. (IMO, FWIW, etc.)