Drafts currently ships with two Markdown engines:
- MultiMarkdown 6. This is Fletcher Penney’s C implementation, which I have only made minor modifications to wrap the C code in suitable cross-platform frameworks. Currently version 6.5.2 ships in the app.
- GHMarkdownParser. This is an implementation of GitHub-Flavored extensions to Markdown, built on the discount parser. This is also the same GitHub-Flavored parser used in Marked.
The MultiMarkdown parser is great, standard, and not changing, other than to be updated periodically to newer releases.
These have nothing to do with syntax highlighting, that is separate, just with Markdown output to previews, templates, and via scripting.
The GHMarkdownParser is fine. It’s a good, fast implementation, but it not maintained and has a few quirks relative to GitHub’s own implementation. So I have planned for a while to switch to the C-library actually used and maintained by GitHub, cmark-gfm.
There are a few differences, like GitHub’s version converts
[ ] task marks to checkboxes. There are some different options available as well, but they are similar to those in GHMarkdownParser. And there are certainly syntaxical variances, but it seems like a no-brainer to switch to the version GitHub uses, so as to be consistent and predictable with their parsing.
So, long story already not short, the question is whether there is any compelling reason to keep GHMarkdownParser in the app. I would rather just swap it out and not have the app cluttered with deprecated libraries.
It might cause a few people to have to adjust to some minor Markdown syntax difference between the parsers, but I doubt it would even be noticed by most - and the C-Mark implementation is lightning fast and maintained.
Anyone think of any compelling reason not to just dump GHMarkdownParser and replace it with cmark-gfm?