Dev meeting 20200623

Attendees

• Charles-Edouard Lecat (@clecat)
• Nicolás Ojeda Bär (@nojb)

General direction of the project

We agreed that the project should aim for:

• Full commonmark compatibility
• Support of "usual" extensions (Github, Pandoc), with precendence: Commonmark > Github Flavored Markdown > Pandoc.
• May grow towards "pandoc" lite functionality if there is interest (eg the Latex backend by @clecat).

The main programmatic interface is the AST exposed by the library. The downside of this representation is that each time it is changed (say, to support a new extension), all the code written against it will need to be adapted. However, the AST is quite small so we don't expect this to be a big problem.

A good project to look at for inspiration: https://github.com/jgm/commonmark-hs, written by the author of Pandoc (who is also one of the main co-authors of the Commonmark spec), a full Haskell implementation of Markdown and its most usual extensions.

• In principle, we don't plan to expose an API to allow the user to write their own extensions (with its own parsers, etc). Doing so would require a complete rethink of the API, as custom nodes in the AST would also be required, etc. Rather, the idea is to use the "attributes" extension (already implemented) and AST-to-AST rewritings to implement the desired functionality.

2.0 release

As per the above point, we decided

• Keep the "attributes" and "definition lists" extension written by @clecat
• Remove the "tag" extension which is "non-standard"
• Try to get a "2.0alpha" release out the door and see if we get any feedback.
• @clecat volunteers to take care of OPAM packaging

With respect to Omd 1.0, the new version has much better support for Markdown (passes the majority of Commonmark spec tests), and exposes a nicer AST for programmatic use. On the other hand, most of the "extra" functionality has been lost in the rewrite (anything apart from Markdown-to-HTML conversion).

The idea is to make the release and see what is needed/requested by the users out there (right now we have no visibility on what/how Omd is being used for).

Post 2.0

One obvious idea is to extend support to each one of the "usual" extensions (GH-flavoured markdown, Pandoc). In order to do that we need to clean up the parser before it becomes a maintenance problem (like the previous parser). @nojb has some ideas borrowed from commonmark-hs to refactor the parser in a way that will make it easy to extend.

The LateX backend is also delayed until after 2.0.

And, of course, we will try to incorporate any feedback that we get from the release.