converting things into ‘math’ should be an extension. But simply ‘indicating’ that something is maths could be allowed for (e.g. marking that section as maths for mathjax to convert), would be smart.
Btw do you mean this? $1+1=2$? Well what if someone wants to type some currency terms e.g. $32
But the block idea doesn’t sound too bad, it reminds me of code blocks.
$$$$$$$latex
1+1=2
\frac{1,2} = 0.5
$$$$$$$
Though I would wonder why can’t we use something like code fencing to deal with this. E.g.
Read the quote from pandoc from my previous comment.
The difference between two dollar signs for math and simply labelling it as ‘latex’ code is that the dollar signs indicate that we want something like mathjax to process this as math and display it better (like how mathjax converts it to how you would actually write it with a pen). But if it’s latex code, we don’t want that, we just want to label it as code and display the characters/code as is, usually with a monospace font, because it’s the code itself we are interested in, not the equation/math. (Maybe also syntax highlight it, which is common with code.)
I think we are talking about different things here.
I was talking about a much simplified, not latex related math support for markdown. Just for very simple math formulas, for the more difficult math formulas, we have MathJax.
The other thing is, having support for MathJax. Which is way more imporant, than my silly proposal. Not that MathJax should be included out of the box, but it would be great if it is possible to add MathJax to any CommonMark editor, just by adding the MathJax script to the website. To let this work, anything between $…$, $$…$$, \(…\), \[…\] should be ignored by CommonMark.
Just thought of another nifty extension, evaluable maths
if this is displayed maths
$ 1+1 = 2 $
Recall: general directive syntax ![](){} (shorthand for !default[](){} )
Then what about using this syntax !$ ... $ or !eval$ ... $ or if that is too confusing for the parser then try !eval[ $ ... $ ] ( Recall $ for inline and $$ for block in latex)
Note that IPython already implements this feature in the IPython notebook’s flavor of Markdown: $…$ is converted into an equation via MathJax.
(In the Julia language, we are considering using Markdown for docstring-like documentation, and we are planning to imitate IPython’s $…$ equation syntax. Since Julia is aimed at technical computing, equations in documentation are essential.)
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.
