Footnotes not working with autolink when its including "w" ?

[fukayatsu]

Firstly, thank you for creating this gem :)

I got odd results from render_doc when :FOOTNOTES and :autolink are enabled, and footnotes including w charactor.

$ irb -rcommonmarker

> CommonMarker::VERSION
=> "0.18.2"

# Expected
> CommonMarker.render_doc("[^w]\n[^w]: foo", [:FOOTNOTES]).to_html
=> "<p><sup class=\"footnote-ref\"><a href=\"#fn1\" id=\"fnref1\">1</a></sup></p>\n<section class=\"footnotes\">\n<ol>\n<li id=\"fn1\">\n<p>foo <a href=\"#fnref1\" class=\"footnote-backref\">↩</a></p>\n</li>\n</ol>\n</section>\n"

# Not expected
> CommonMarker.render_doc("[^w]\n[^w]: foo", [:FOOTNOTES], [:autolink]).to_html
=> "<p>[^w]</p>\n" 

# Not expected
CommonMarker.render_doc("[^power]\n[^power]: foo", [:FOOTNOTES], [:autolink]).to_html
=> "<p>[^power]</p>\n"

# Expected
> CommonMarker.render_doc("[^foo]\n[^foo]: foo", [:FOOTNOTES], [:autolink]).to_html
=> "<p><sup class=\"footnote-ref\"><a href=\"#fn1\" id=\"fnref1\">1</a></sup></p>\n<section class=\"footnotes\">\n<ol>\n<li id=\"fn1\">\n<p>foo <a href=\"#fnref1\" class=\"footnote-backref\">↩</a></p>\n</li>\n</ol>\n</section>\n"

Is there any workaround for this?

[kivikakk]

There's an open issue for this at github/cmark-gfm#121 -- there's no proposed fix yet, unfortunately.

[gjtorikian]

As this is an upstream issue I'm closing this issue out. ✌️

[fukayatsu]

oh, Thanks for pointing out.

[fujimotos]

@gjtorikian Evidently this issue has been fixed by github/cmark-gfm#229 and included in the latest release in the upstream.

Can you bump the version and create a new release that include the fix?

[gjtorikian]

@fujimotos This was merged in #148 and already released as 0.23.2. Have you tried that version?

[fujimotos]

@gjtorikian It turned out that the root issue was github/jekyll-commonmark-ghpages relying on an ancient version of this project.

It still uses 0.17.x, so we didn't saw the fix:

https://github.com/github/jekyll-commonmark-ghpages/blob/master/jekyll-commonmark-ghpages.gemspec#L18

I can confirm 0.23.2 fixes this issue. So thank you!