CommonMark now in use on GitLab


#1

GitLab Flavored Markdown has now been migrated from using Redcarpet to CommonMark.

Mostly painless, though we did have to run our own documentation through diff_redcarpet_cmark in order to ferret out some of the differences between Redcarpet and CommonMark.


#2

Your documentation needs some cleanup, though, because it puts some features under the Standard Markdown heading that are neither in Commonmark nor in Gruberʼs specification, e.g. strike-through and tables.

It is not really helping that your are using the same acronym, “GFM”, to refer to GitLab Flavored Markdown that everyone else is using for GitHub Flavored Markdown. You should probably also document the differences between the two, e.g. $`inline math`$, fenced block quotes >>>, videos ![](foo.mp4), diffs [+ ins +] {- del -}.

We should really get on publishing extension modules with test cases, so implementations can claim interoperable conformance to them. They often differ in details, e.g. Gitlab apparently requires exactly two tildes ~~ before and after stricken text while Github collapses any matching number of tildes (like `).


#3

Perhaps we should set up a seperate CommonMark community GitHub organisation to coordinate the development of the extension specs and reference implementations? Similar to how the React Community GitHub is seperate from the main React organisation, with the ownership of repos being temporary for long term maintenance.


#4

I certainly would contribute some documentation if there was an agreed upon format and place for it.


#5

A good starting point might be to seperate the spec generation tool(s) in the CommonMark repo into a reusable tool that can be used to also generate extension specs.


#6

@Crissov thank you for pointing out the misplacement of the tables, I missed that. I’ll work on getting some of those changes in.

I agree that we should start making real progress on extensions. I think that’s one of the biggest weaknesses of CommonMark at the moment. I think we all agree there needs to be a well defined set of extensions. The longer we wait the more there are different implementations, which is exactly the problem we had with Markdown.


#7

#8

Awesome, thank you for creating the merge request!