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
> [[plugins/contrib/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
> [[plugins/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>
[[!tag patch]]
[[!template id=gitbranch branch=jon/commonmark author="[[Jon]]"]]

> 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?
>
> &mdash; *[[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](https://gitlab.com/anarcat/scripts/-/blob/a6dbda602d8d8e9c0ef810d308e35a09ff538836/in-debian), 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

> I tried this patch on Fedora 39 (which has perl-commonmark 0.290000 and libcmark 0.30.3 packaged),
> but immediately encountered a problem where all wikilinks and directives stopped working.
> `\[[foo]]` in the source page becomes simply `foo` in the generated HTML, as if CommonMark ate the double brackets.
>
> I don't have a different system to compare if it's specific to the Fedora packages. Did you face this problem?
>
> -- j@ustink.org 2024-06-29

>> Embarrassingly, yes. I've just (re-)confirmed this with libcmark0.30.2 and libcommonmark-perl 0.310100-1.
>> I should have a fix pushed tonight or Tomorrow.
>> &mdash; *[[Jon]], 2025-09-12*

[[done]].
