Yes, all the time I was fully aware that I was using features that can be plugged in and plugged out. OTOH, I had no idea of the demarcation of involvements and definition of responsiblities with respect to plug-in production. The answers of @tessus and @laurent leave me with the impression of a collection of unidentified third parties (UTFs) that can only be controlled to some extent by best effort. This setup doesn’t look as being the most mature part of how the development of Joplin is organized.

I also realized that using some features would possibly make my writings incompatible with the outside world. I don’t care much about that aspect, as the outside world is incompatible with itself, and only Pandoc is trying to understand all Markdowns (including its own one). I did some googling today, and these look currently the most prominent ones to me:

(layed out according their presumed lineage). This is only the top of the iceberg. See and try Babelmark. I wonder if using Markdown is a good choice. Why not AsciiDoc (see also AsciiDocter) or reStructuredText (reST)? No forks of them known to me. Okay, Markdown is unmistakably the most popular… because it’s the most popular. The de facto standard .

When I was thinking about a new desired Markdown extension, I couldn’t resist peeking into some plug-ins to get an idea about how complicated it would be to create them. I didn’t delve very deeply, but nevertheless I noticed that a lot of parsing was done by plain JavaScript. Exclusively, or with help from some non-JavaScript libraries? I don’t know. And I saw a lot of apparent interface overhead. The current plug-in provision is not as flexible as in my web browsers: 14 are pre-installed, no more, no less, exactly those 14. Can it be made more open? An interesting question. The order in which parsing algorithms are processed may decide the result. So some centralized orchestration of plug-ins seems inevitable.

Anyway, my table case can be closed.