Need link to spec in readme + document deviations

[rlidwka]

Readme has spec 671/671 as a badge on top, but it doesn't mention anywhere what spec that is.

I've noticed, that cmark-gfm changed their spec.txt recently (to the point that it's not commonmark anymore): https://github.com/github/cmark-gfm/commit/828322d1ee4facdab56f0d3edccb13e9af90dcd2

But the actual specification published by github doesn't have those: https://github.github.com/gfm/

This creates confusion about what spec is being used. Thus, I'm asking that spec 671/671 badge would link to spec currently followed by the parser.

Also, "100% CommonMark-compatible" statement might no longer be true (****because of this****). Maybe document what changes from it are present, and whether it's possible to engage commonmark-compatible mode?

[digitalmoksha]

I tend to agree with this - although comrak is now cmark-gfm compliant, I think we should make sure that it's CommonMark compliant as well. I'm not sure why they did what they did.

It is a bit redundant to output multiple levels of <strong> when it's not needed - I wonder if it's worth seeing if the reference implementation would change.

Otherwise, it might be worth adding another flag, either named specifically for this particular handling, or named something more generic. I'm drawing a blank at the moment...

[kivikakk]

Thanks for this report @rlidwka, and your thoughts too @digitalmoksha!

I agree, and there's no reason why Comrak can't do both. The CLI program has a --gfm flag which is as close as we get to recognising GFM as its own mode, so let's add a gfm_quirks option which covers these divergences, enable it in --gfm mode, and use that when executing against cmark-gfm's (modified) specs.

We'll also pull in the upstream CommonMark spec and run its spec test against Comrak running in its default (non-GFM) mode, and that'll be the benchmark for what specs we pass when we talk about "CommonMark compatibility".