I suffer from the occasional markdown glitches using branchable.

I've found that switching my own non-ikiwiki projects to https://github.com/jgm/CommonMark has helped sort them out for the most part.

ikiwiki does not implement Markdown on its own: it uses one of several third-party libraries, with the current recommendation being Discount. Out-of-process implementations like pandoc are not suitable to be the default for performance reasons.

There seems to be a Perl binding for libcmark at https://github.com/nwellnhof/perl-commonmark, but unfortunately its README points out that the libcmark API is not stable, which means libcmark and perl-commonmark would have to be upgraded in lockstep: this makes them awkward to deal with in Linux distributions. As a result I'm not going to look into this myself until there is a stable API for Commonmark available in Debian.

However, if you want to add optional Commonmark support to the mdwn plugin, I'd review a patch. --smcv

A very initial patch is here. There might be ikiwiki-to-commonmark option translation to do.

Patch: https://github.com/jmtd/ikiwiki/commit/c76eeac8152604ce3d7d1672fe404c8ee8ef2dd8

I'm starting to review outstanding IkiWiki patches, and this one was an early candidate because it's so trivial, but I have some questions to resolve.

1. In order of preference, I've inserted this after multimarkdown and Discount, but those are only enabled if they are explicitly selected; Commonmark is ahead of the remaining implementations that are checked for (Text::Markdown, Markdown, /usr/bin/markdown), and so if available, would take precedence. Is this reasonable?
2. Should one be able to explicitly force Commonmark, like one can with multimarkdown and Discount?
3. I'd not use gettext in the debug print now.
4. I need to double check why I've used -> instead of :: (thanks anarcat)
5. Per smcv's comment above, what's the status of the Commonmark library in Debian now?

— Jon, 2024-02-22

I'd say:

1. yes, new implementations should be deprioritised unless a strong rationale is given.
2. That would be great, but I wouldn't make that a blocker.
3. no opinion
4. nod
5. as far as I can tell from my magic script, neither libcmark or libperl-commonmark are packaged. There isn't even a WNPP bug. I do wonder if that's a criteria for inclusion though; I wouldn't keep code away merely because it's not in Debian. (What is our criterion, actually? I'd say "unit tests and integration in CI", but, while we have the former, we don't have the latter, and not having Debian package might make testing this harder.... )

-- anarcat