Math equations
rossant opened this issue · 3 comments
Do you plan to support math equations, for example enclosed between $...$ or $$...$$? The CommonMark spec doesn't seem to support it, although there are discussions about it.
If the answer is no, is there any way for a third-party library to implement a parsing extension for CommonMark-py?
If the answer is still no, I guess a hackish workaround might be to parse a document manually right before passing it to CommonMark-py, replacing $y=x$ by $y=x$, and transforming the corresponding Code nodes by new Math nodes in the AST.
I can't speak for the other people working on this repo, but personally I don't plan on implementing this math feature in this library in the near future.
I think that a feature like this would work fine as a post-processing step, separate from CommonMark-py. For example, I use commonmark in my office's project management system for comments. After processing the user's text in commonmark, I run the results through bleach.linkify() to turn any URLs into clickable links automatically, since no one (including myself) ever remembers to add markdown's < and > characters on both sides of the link.
So, I could imagine some sort of markdown-math processor to achieve this, I just don't think it belongs in this library if it's not in the CommonMark spec. If you found some way to implement this in a way that didn't interfere with the main commonmark code too much, that might work, though.
OK. I just implemented a separate preprocessing step before passing contents to CommonMark-py, and it seems to work (at least on simple cases). In my case I need to wrap math contents within code elements, otherwise things like $a_0 + a_1$ will be messed up because of the double _. I can then detect these special code elements and convert them to Math elements in the AST.
I'm +1 on an extension for math (both inline and block level).
@nikolas This will not work as a post-processing step, because it has to happen before escaped punctuation is handled and, as @rossant mentioned, before inline Markdown formatting is handled.
It would be really great if this could be handled as an extension during parsing.