GitHub is now using CommonMark and a modified version of cmark


#1

#2

Anybody knows, where the Markdown source for the GFM specs is located?

I cannot find it in the https://github.com/github/cmark/ repo. It would be cool to have it available as I’d like to make MD4C extensions more compatible with that (and perhaps implement complete support for the GFM dialect), and it would be useful for testing purposes.

EDIT: Sorry. Ignore this post. The spec update is directly in test/spec.txt. I cannot see how I overlooked that.


#3

Just to call out areas where CommonMark needs to have established, blessed extensions early on:

Most notably, support for tables, strikethrough, autolinks and task lists are missing.

I don’t feel Task Lists has a strong use case outside GitHub, but tables, strikethrough, and autolink are very defensible as common extensions that will be used frequently in the wild.


#4

autolinks is already used in the spec as the name for links like this: <http://example.com>. What they mean, no doubt, is an extension that turns anything that looks like a URL into a link. (To avoid confusion, they should not use autolinks as the name of this extension.) I’m skeptical that this belongs in the spec. Recognizing URLs amid possibly surrounding punctuation is a tricky business that requires lots of complex heuristics.

Tables, certainly. Strikethrough, okay. But more important than strikethrough: latex math, definition lists, arguably also footnotes.


#5

First off, I think this is awesome. I’ve been incorporating CommonMark in a product for over a year. I think it’s great to have one of the major users of Markdown clearly adopt it. And to create a spec for their extensions, which are very widely used. I expect CommonMark will be more quickly adopted now.

I disagree that task lists don’t have a use outside of Github. I’ve found them used in many documents and markdown editing software. Obviously it’s not a core item, but as a blessed extension, for sure.

Anyway, awesome…


#6

Perhaps links wrapped in angle brackets should be given another name in CommonMark since they are not completely automatic; the surrounding angle brackets have to be added manually to the make the URL become a link. The word “automatic” is surrounded by quotes in the original syntax guide implying that these links are not really automatic. Title-less links?


#7

Hear, hear! As noted, these are already fairly common “extensions” in the wild, and far from niche in terms of use case.


#8

Any chance to have some kind of Math support for 1.0?

Or at least define $ <Inline Math Code> $ and $$ <Paragraph Code>$$ as decorators for math?

Thank You.


#9

Does anybody know what the plan for Github Pages is?

I just set the markdown engine to CommonMarkGhPages and got an email warning me to better change it to kramdown, linking to Updating your Markdown processor to kramdown.

But as far as I know, kramdown is not commonmark-compliant, so is github pages just going to continue using a quite different flavour than the rest of github, or…?

P.S. I asked this directly in a jekyll-commonmark-ghpage issue.


#10

I replied over on the issue, for completeness quoting here:

Your use here is correct – that email is being sent in error. We actually internally call that renderer gfm and have been advising users to use that value, rather than CommonMarkGhPages, and weren’t sending the email out in that case. I’ll fix it so both values prevent the warning email.