this got me thinking that we should provide support for consistent ways to implement inline code snippet evaluations via !eval[](){}, not just for latex commands. Maybe it could process python snippets as well.
Imagine being able to run multiple styles of codes on the same page. E.g. a section in matlab, a section in python, with latex mathematical proofs evaluated that is self tested. etc…
I think math is important enough to deserve a special $…$ syntax. I agree with rwzy that Pandoc’s syntax is common enough, and has proved itself so usable in practice (e.g. in IPython notebooks), that it is worth recognizing as the de facto standard.
(Note that IPython and Pandoc also support $$…$$ for block equations.)
I don’t think that all conformant Markdown implementations should be expected to support LaTeX equation rendering, but as a fallback they should leave $…$ and $$…$$ blocks alone (or perhaps render them as code).
The $…$ looks intersting, but I believe it needs to be refined to avoid ambiguities. In the following sentence
This diamond is worth sometwhere between 500$ and 700$
you would have an inline math expression and 700. To prevent this, the $…$ could be turned into a block level expression. E.g. we could say something like the first $ has to be the first character of the line, followed by two spaces and the line ends with two spaces followed by a $. E.g.
$ 1 + 2 = 3 $
I believe in this example, the $ signes would not be too disturbing while reading the plain text to get closer to what @Kasper was asking for in the first place.
I personally don’t like the $ sign, because it is already used for so many things in non mathematical context. For money, for variable names etc. Therefore, I would prefer using code fencing like
But with this example, we are getting further away from what @Kasper originally asked. There would be too much stuff around each equation, if you put explanations between each equation. Tricky…
What about using a different symbol combination, that is attracting less attention on itself and is less used than the $ sign E.g two dashes and one space:
No, this would not create an equation in the pandoc syntax, because the first $ does not have a non-space character immediately to its right. Similarly for the more-standard format “$500 and $700”.
If you mean sites that simply process through a markdown->html converter, then run mathjax on the resulting page, the problem with that is not just cumbersome syntax but bugs where markdown interprets charcters inside the math, notably _ or *:
$A*B + C*D$
→ $A<em>B + C</em>D$ $\\vec{x}_y$ is coprime to $a_{b,c}$
→ $\vec{x}<em>y$ is coprime to $a</em>{b,c}$
which confuses or completely breaks the math rendering, and leaves blocks of text randomly italicized.
Thinking through double processing is not something that should ever be inflicted on users…
The only healthy thing to do is for markdown parser to preserve and mark math blocks (e.g. <span class="math">) and disable mathjax processing outside of them.
The markup syntax (makdown+iTeX2MML) implemented in instiki wiki project, seems me very good. I suggest a look .
As noted above, the problem with that syntax is that \[ and \( already have clearly defined meanings: they are escaped [ and ( characters, and it is very important that there be a way to escape these characters in certain circumstances.
But I’m certainly in agreement about the importance of supporting math.
Hi, I’d just like to point out that the discussion here about not parsing contents surrounded by some kind of special delimiter has a strong connection with an earlier thread in no-markdown islands.
I guess this is an opportunity to tackle a better and simpler solution than have the spec addressing math specifically. Even though my main usecase for opening that thread is my experience using LaTeX/MathJax with several parsers, I see it as not fundamental regarding the problem of literal data inside CommonMark content.
One single and short approach to this in the spec could solve anything related to supporting MathJax, LaTeX mixed with CommonMark, or other kind of literal data that must end up as-is in the output after the parsing phase, not mattering whether it compiles to HTML, LaTeX or other thing.
This is not an area that I am familiar with, but at least for blocks of math I don’t see why fenced code blocks couldn’t be used:
```math
2^2=2*2 = 4
1/2 + 1/2 = 1
(x+1)/(x-1)
(a + b = c) => (a = c-b)
```
The presentation of the block could be handled by CSS and/or another parser designed specifically for displaying math. Essentially, math would be treated as just another type of code.
Inline math is more difficult if you want to style it a particular way; there is a similar problem for inline programming code.
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:
I dont know mcuh about the internal details of commonmark, but I had used the code from StackExchange site (The license is unknown) @ https://github.com/meghprkh/markdown-mathjax 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.
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).
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?
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?