On Monday, 11 December 2017 at 00:54:00 UTC, Walter Bright wrote:
I have a more pragmatic definition of a standard:
1. Products that implement it say they adhere to it and defer
to it as the authority on correct behavior.
2. There's more than one such product.
You have to start somewhere. Somebody has to put the second
product out there.
3. There's more products adhering to that standard than some
other competing standard.
"In 2017, GitHub released a formal specification of their GitHub
Flavored Markdown (GFM) that is based on CommonMark.[32] It
follows the CommonMark specification exactly except for tables,
strikethrough, autolinks and task lists, which the GitHub spec
has added as extensions[33]. GitHub also changed the parser used
on their sites accordingly, which required some documents to be
changed, e.g. a space after the hash signs of a heading is now
required."
(https://en.wikipedia.org/wiki/Markdown#GFM)
If GitHub is not some sort of "standard" or at least a good
indicator of where things are going, I don't know what is.
So basically, CommonMark is the standard for GitHub. It merely
added some extensions that are useful for GitHub related stuff.
This means that millions of programmers are already familiar with
CommonMark and use it on a daily basis. This in turn would make
it easier for them to read and contribute to D source code.
Sometimes simple things like that can be the straw that breaks
the camel's back (and Ddocs certainly put people off (including
me)).
So far as I know, commonmarkdown satisfies zero of those.
Don't get me wrong, I think commonmarkdown is a worthy effort,
and is definitely in the running to be a standard. Certainly a
lot more effort seems to have been put into it vs other
markdowns. It is entirely reasonable to refer to it to answer
questions about whether some detail should yin or yang.
But implementing commonmarkdown in Ddoc is not what we're going
to do, at least for the near term.
Hm. I'd really give it a second thought.
