Hi All,
I have a fork of jekyll that adds support for using pandoc (actually, pandoc-ruby) for the markdown conversion. Pandoc has built-in support for a variety of math output formats, including mathjax; it has built-in support for bibilographic citation processing using citeproc and csl styles (the same standards used by Zotero); it has built-in support for code highlighting. It is one of the most robust implementations of markdown there is, with a carefully thought out set of extensions and features. There are lots of reasons why someone might want to use pandoc as their converter when using jekyll.
The only changes made are in
Would the developers consider adding support for pandoc-ruby to jekyll, assuming I had a nice clean and appropriate fork with appropriate tests? (Right now, my fork has one feature that would need to be removed, on lines 17-26 of the forked version of markdown.rb.) I ask here because an old issue I posted on github (issue #155) received no response, and I've noticed that similar requests for multimarkdown support have gone unanswered too. So I don't want to spend time on making this clean and appropriate if it is the settled view of the developers that such support should not be added.
To be clear, I am not asking for github pages to support pandoc-ruby, just for jekyll to do so (some of the requests for multimarkdown support have been ambiguous on this question).
If support for additional markdown converters is not going to be added, I have another suggestion, per issue #203 and
https://github.com/mojombo/jekyll/issues/289#issuecomment-1324256. At the moment, converter plugins cannot override the default converters. So the only way to add a markdown converter without altering markdown.rb is to write a plugin and use a different extension (".pandoc", say, or ".multi") for one's input files. But that seems like the wrong way to go about things when the input files are markdown files, and means that the conversion cannot gracefully fall back on github. Is there a reason why the default converter must be given highest priority? If not, would it be possible to add support for converter plugins that override the default converter for a given input format?
This alternative actually seems more elegant and perhaps a better long term solution: god knows there will always be yet another markdown converter around the corner, and someone will want their favorite converter supported. A working plugin architecture is the natural way to solve the problem.
Thanks,
David