4 ms·

This is very similar to Pandoc, which also processes things into its own AST/Internal representation. It then knows how to translate its representation into a m

This is very similar to Pandoc, which also processes things into its own AST/Internal representation. It then knows how to translate its representation into a many different outputs. Pandoc is really nice and you can script it with a variety of languages, though if you really want to dig in you have to use Haskell. Kramdown using Ruby makes it more accessible and has some cool options like table of contents generation that is more flexible than Pandoc. You can see some discussion of supporting Kramdown in pandoc. https://github.com/jgm/pandoc/issues/2711 https://github.com/jgm/pandoc/issues/2711 Generally I think pandoc is the more mature tool, but I can see places where it might be a better call (especially if your app needs it as a library and you aren't willing to call a command (Pandoc).

cel1ne 10y ago
I use pandoc to convert the electron API-doc from markdown to XML. Then I use XSLT to create kotlin bindings: https://github.com/fab1an/kotlin-electron-api https://github.com/fab1an/kotlin-electron-api XSLT still rules for content-transformation.
nerdponx 10y ago
In my opinion, Pandoc is by far the best Markdown parser nowadays because it can be configured to support just about any Markdown flavor you can think of. Kramdown meanwhile seems to lack that configurability, and moreover has somewhat nonstandard support for in-line math. I switched to Pandoc on my Jekyll site and never looked back.
- geraldbauer 10y ago
  > Kramdown meanwhile seems to lack that configurability FYI: To configure kramdown such as using GitHub-flavored markdown (GFM) or using govspeak or slackdown etc. you use a new/different parser class. For example to use GFM in GitHub Pages / Jekyll in _config.yml add: kramdown: input: GFM Cheers.