Mathematics extension

I strongly support inclusion of Pandoc-style inline math notation, with at least the status of “you don’t have to do anything with this, but you must still parse it correctly”. For instance, in

Let $y = m * x + b$ where $b$ is US$50,000

the asterisk in m*x should not be interpreted as an emphasis marker, and conversely, the dollar sign in US$50,000 should not be interpreted as a math shift.

Displayed equations are more complicated — I’m not a mathematician, and yet, in every paper I’ve written that had even a little math in it, I’ve found myself reaching for \begin{align*} and friends from amsmath. As such, I would prefer fenced-block syntax for display math, with implementation of the full amsmath repertoire of math environments encouraged.

Note further that displayed math can plausibly have text nested inside it, with inline math nested inside that:

   a(t) = \begin{cases}
          a_0 \sin kt & \text{when $a > 0$} \\
          0           & \text{otherwise} \\

and it’s not out of the question that someone would want to put inline markdown markup inside \text{...} as well.

What is the difference between this proposal and: MathJax extension for LaTeX equations

I recommend editing it to the description.

I dont know mcuh about the internal details of commonmark, but I had used the code from StackExchange site (The license is unknown) @ and modified it for the different kinds of latex operators.

It finds valid latex (brackets matching) and replaces it with text @@number@@ while indexing other entries of such form.

Then It uses markdown to parse it and then rereplaces it wih the original text.

The only bug is that it should have been able to isolate code blocks.

For eg. the following would render incorrectly \(x`^2`\) when you use code highlighting etc, for the original text is replaced after markdownn has finished.

(My link used marked)

@jgm, is it possible to push forward markup draft for math ?

  • block style
  • inline style

By formats:

  • latex
  • asciimath (for non-tech users)

References for renderers:


I think your link to KaTeX is is wrong.
KaTeX does look amazing.

By the way, I don’t know who runs this forum, but you can sign in using Yahoo ID yet you can not Login using it (By pass is to use the Sign Up again and again). - that’s a right link. Can’t edit original.

Regarding the original idea of simple ascii math conversion: It might raise major issues regarding conversion, as there are too many ambiguities. Should 1/2 be 1/2 or ½? Should => become or are there common cases where it means literalla =>?

Note by the way that most latex special characters are also available in unicode, so maybe some things are better left to the editor than to the converter. (See e.g. Emacs with M-x set-input-method TeX).

Another issue I am interested in would be cross-references. Does the specification currently allow for extensions that would allow cross-referencing equations in the style of LaTeX’s \ref and \label macros?

@vitaly, KaTeX looks great.

I hope Math support using $ $ and $$ $$ would make it into the Spec.
It works amazingly well in StackEdit.

Including support for complicated LaTeX templates.

Thank You.

I’ve just opened another thread Ignore TeX-like Math mode (or parse it) as at leas the title of this thread suggests that CommonMark should basically do what MathJax is currently doing.

I have implemented parsing math inline of $...$ and $$...$$ and I followed mostly how parsing is done for emphasis delimiters, but I’m not really convinced this is the best way to do it. I would in fact expect $...$ and $$....$$ to work a bit like a string with quotes (but would just allow escape with \$).

But looking at pandoc for example, with the following case:

This is a test $$this is a test$

it is generating this:

<p>This is a test <span class="math inline">\($this is a test\)</span></p>

Unlike delimiters, I would expect that a $$ should match an ending $$

I’m not sure how Latex behaves with this. Is this the way it is usually handled?

Did a great job in this thing.

One thin I want to ask is whether we can make the system work faster. Because this plugin is very powerful, but not so quick.