Hi all, I’ve written an experimental Markdown parser that will also handle TeX/LaTeX style math formulas. Here is a demo app, with the code at jxxcarlson/math-markdown.
I’d be very interested in feedback, especially regarding Markdown text that is not properly handled. Markdown has a quite irregular syntax, and I’m not confident that I have handled it sufficiently well.
The idea with this is to have a convenient way of writing lightweight math articles – short class notes and assignments, for example – where the full power of LaTeX is not needed.
The parser is pure Elm, and can be used without the math part. See the two examples in the source code:
./app-plain. In the former, the
index.html file calls on
MathJax.js via a custom element (thanks @luke !); in the latter, then
index.html file only defines some CSS styles and calls on highlight.js for syntax highlighting
This looks wonderful!
What would you think about approaching this slightly differently? What if the math and poetry notations were plugins to a general Markdown parser/renderer? You’ve already done the hard part in writing the parser, and you already have both an inline and block extension that you know you want!
Oh, and what version of markdown does this use other than the extensions? Commonmark?
Hi Brian, thanks so much for the comments. I’ve been playing around with the your plugin suggestion, which I like very much. The approach I’ve taken for the moment is to add
type Option = OMath | OVerbatim | OPoetry and then add an
option : Option parameter to the functions that need it. The problem I am struggling with at the moment is that
option has to be threaded through the entire parser module and a couple of others as well. Lots of functions. Is there a better approach?
I tried to follow Commonmark, but I must say that Markdown is such a hairy beast that I have only made a first step towards compliance. More work needed.
I’ve found some interesting reading on the subject (see below), and am going to cogitate more on this before I try to adhere better to the standards. I do have tests, but need many more
Beyond Markdown: MacFarlane
Coding Horror on Standard Markdown
nope, that sounds about right . I can think of a couple variations:
- pass in a
Parser a instead, which can be like
oneOf [ math, poetry ].
- return an AST instead:
Markdown, where members are like
Paragraph Inline | List Inline (List Inline), et cetera. Callers perform further parsing on the result.
- do both (my fav) and make
parse : Parser a -> String -> Markdown a. Lets you render using things that aren’t
Thanks! I think I will go with something like your option (3). I realized while doing errands to day that I can render the AST to LaTeX which believe it or not has advantages, e.g., ship it out to make PDF.
This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.