How does this differ from jekyll-commonmark-ghpages?

[0xdevalias]

(similar question posted at github/jekyll-commonmark-ghpages#17)

I notice that while the readme for this project talks about using libcmark, it actually appears to achieve this via the commonmarker gem.

Looking at commonmarker, it talks about being a ruby wrapper for libcmark-gfm, which apparently includes all of the GFM extensions already:

Ruby wrapper for libcmark-gfm, GitHub's fork of the reference parser for CommonMark. It passes all of the C tests, and is therefore spec-complete. It also includes extensions to the CommonMark spec as documented in the GitHub Flavored Markdown spec, such as support for tables, strikethroughs, and autolinking.

This would make me think that jekyll-commonmark by itself already supports GFM.

--

Adding jekyll-commonmark to my Gemfile resulted in the following in my Gemfile.lock:

jekyll-commonmark (1.3.1)
      commonmarker (~> 0.14)
      jekyll (>= 3.7, < 5.0)

commonmarker (0.21.0)
      ruby-enum (~> 0.5)

Resetting, then adding jekyll-commonmark-ghpages to my Gemfile resulted in the following in my Gemfile.lock:

jekyll-commonmark-ghpages (0.1.6)
      commonmarker (~> 0.17.6)
      jekyll-commonmark (~> 1.2)
      rouge (>= 2.0, < 4.0)

jekyll-commonmark (1.3.1)
      commonmarker (~> 0.14)
      jekyll (>= 3.7, < 5.0)

commonmarker (0.17.13)
      ruby-enum (~> 0.5)

By the looks of this, by using jekyll-commonmark instead of jekyll-commonmark-ghpages I would actually be getting a more up to date version of commonmarker (and thus the underlying c implementation), that supports GFM. Which to me, at face value, is definitely not what I would have expected.

[pathawks]

It is my understanding that the commonmarker Gem that we require is merely an FFI wrapper around libcmark. If that is no longer the case, we can certainly update this project or at least update the Readme.

To answer your broader question: ifI remember correctly, we both started at around the same time. My intent when starting this project was (primarily) to utilize the fastest Markdown processor available in Ruby and (secondarily) conform to the then emerging CommonMark spec. I imagine the GitHub Pages team is more focused on building a processor that behaves similar to the GitHub Flavored Markdown processor used on the site. The fact that we are both using the same tech under the hood is kind of an implementation detail. 🤷🏼‍♂️

I hope this answers your question. 👍🏼

[0xdevalias]

Thanks for the quick reply @pathawks.

From the commonmarker readme:

Ruby wrapper for libcmark-gfm, GitHub's fork of the reference parser for CommonMark. It passes all of the C tests, and is therefore spec-complete. It also includes extensions to the CommonMark spec as documented in the GitHub Flavored Markdown spec, such as support for tables, strikethroughs, and autolinking.

Quickly skimming through the commit history, it looks like it may have originally used libcmark, but later changed to use libcmark-gfm; so perhaps updating readme/etc here to make that clearer would be a useful step?

[0xdevalias]

I've opened #38 with a few README tweaks to make the current state of things a little clearer.