Robin Stocker

Fix released in version 1.1.3

+1. Any thoughts on this, @jeeeyul?

The [current appveyor config](https://github.com/gnzlbg/ctest/blob/master/appveyor.yml) tests 4 targets. Travis-ci doesn't seem to support all of those: https://users.rust-lang.org/t/testing-i686-pc-windows-gnu-using-travis-ci-new-windows-jobs/21932 If that doesn't matter, I can raise a PR for switching to Travis anyway.

The reason for this is the paragraph parser. The spec says that leading whitespace is skipped: https://spec.commonmark.org/0.31.2/#example-222 Not sure how we would handle it. We can't add the leading whitespace...

See also https://github.com/commonmark/commonmark-java/pull/290#issuecomment-1986613844

> > (cmark behaves differently yet again, for certain code points, [it uses a replacement character](https://github.com/commonmark/cmark/blob/db0da216ba81435ce1547f9d1159a7f91298d187/src/houdini_html_u.c#L90) instead.) > > These code points are the surrogates Ah yes, scratch that part...

Hey! Hmm, interesting. I see footnotes explained in [GitHub's docs](https://docs.github.com/en/get-started/writing-on-github/getting-started-with-writing-and-formatting-on-github/basic-writing-and-formatting-syntax#footnotes) but not in their [spec](https://github.github.com/gfm/). But yeah, would be good to support that. The thing that will be a bit...

Alright, you made me curious and I've started looking into this :). Apart from reverse-engineering how GFM's footnotes work, we can also look at the source code of cmark-gfm. Here's...

Heh, thanks for chiming in :). Yeah for reference links, the definitions are all parsed as part of block parsing, which is the first pass of parsing (before any inline...

Branch here, with block parsing of footnote definitions (that part is straightforward): https://github.com/commonmark/commonmark-java/compare/footnotes-extension?expand=1