Support for Inline and Display Math

[summivox]

I'm working to support MathJax.

Output tag format:
http://docs.mathjax.org/en/latest/model.html#how-mathematics-is-stored-in-the-page

The idea for now:

• $ ... $ => inline math
• $$ ... $$ => display math

The code I wrote is mostly monkey-patching. Could anyone help get it settled?

[jsbeckr]

+1 would love to see this!

[tarqd]

Love the idea but I dislike $$...$$ as it is far more distracting compared to the rest of markdowns syntax (I know it's standard for latex though).

Personally I've gone with a syntax more like $[ ax^{2} + bx + c = 0 ] which is similar to the way you'd include an image in markdown. It also opens the door for other syntaxes like ASCIIMath

$[ ... ]
$[ ... ][amath]
$[ ... ][latex]
$[ ... ][mathml]

[Jerska]

👍

[karan]

I like the syntax suggestion! Would love to see this in Atom soon.

[tarqd]

If you're interested I implemented this in my own fork of marked

[summivox]

Actually I impl'd this as a monkey patch to support MathJax in renren-markdown. I'm enough of all this Markdown-related fragmentation and wish that someday we could really have a blessed "common markdown" or such.

chjj/marked seems to be in a state of limbo -- dunno what's going on or what's the author's plans, but it seems that these will never get merged... sigh...

[nrolland]

there are already many other editors doing this mathjax + markdown, and they stick to latex convention :
$....$ for inline $$...$$ for display

imnsho, the last thing anyone need is a new syntax for latex.
There in a de-facto standard on this, used in ipython notebook, R markdown, stackedit.io, etc....

you can also accept a block syntax to make it more regular if you so wish, but supporting what is now the standard seems a must for usability/interoperabiltity.

[summivox]

@nrolland I know (and have used) the $ ... $ and $$ ... $$ syntax. However this causes trouble as Markdown documents could easily contain $ -- which not very surprisingly means "dollar". This is the only reason I implemented in this PR as $$ ... $$ and $$$ ... $$$.

And, before the big players agree on a "common markdown" I don't think this chaos could really end.

[nrolland]

I am not sure this is wise. If people really mean dollar, they use USD. I dont even know where the euro sign is on my keyboard, or how to do Yen.
Conversely, math is much more common.

As far as I can see, there is little chaos in that matter : editors have settled for latex convention.

[scottgonzalez]

If people really mean dollar, they use USD.

That's far from true for the majority of people.

I dont even know where the euro sign is on my keyboard, or how to do Yen.

That's completely irrelevant to the discussion. The equivalent argument is that I don't know latex.

Conversely, math is much more common.

Do you have any statistics to actually back that up?

As far as I can see, there is little chaos in that matter : editors have settled for latex convention.

I think this is a strong argument. If there are multiple implementations that already follow this convention, then deviating from this convention is harmful. Including the mathjax option and defaulting it to false would prevent any accidental breakage anyway.

[nrolland]

Since the statistics to back that up would be the same than those which backs your argument about "the majority of the people". I dont have them, you dont have them, we are talking opinion here.

At the level of opinion, me not knowing where the euro or yen symbol is despite working for 10years in finance is relevant. The equivalent argument would be you ignoring latex despite being a mathematician typing electronic math for 10years. I guess that would say something about the relevance of such system.

My guess though is folks who type € for EUR, $ for USD, ¢ for cent (just discovered that one, cute), ¥ for JPY, ?? for CNY (can't find it..) use Word or any other general editor, not a fancy new markdown format. let's see in 5 years if that guess is proved correct.

In the meantime, there seems to be a standard, and it it not in favor of funny currency signs.

[nrolland]

The "common markdown" concept would be a very good thing though.
(Conceptually, its structure would make blocks similar to cells in markdown.
possibly with some extension protocol to pass on environments/notifications
but that is a different issue)

[marfarma]

I don't understand the difficulty with the $. A single $ is an inline expression, it has to be matched to a closing $ within the same block. If there are two $ currency symbols in the same block -- and mathjax is enabled -- the user is likely to recognize the problem and take appropriate action.

So what is the appropriate action? How can the $ symbol be escaped, so that it's not processed as a mathjax open inline block indicator? Let's see how it works on math.stackexchange:

Special characters used for MathJax interpreting can be escaped using the \ character: $ $, { {, _ _, etc.

Why not follow suit?

[marfarma]

Based on how the quoted comment rendered, backslash already escapes the curly brace and the underscore -- so it's probably just a matter of adding the $ symbol to the list of 'escape-able characters' in the same block of code.

[summivox]

@marfarma : Makes sense. Changed.

@nrolland @scottgonzalez : My fault to bring up the "currency" issue. It's clearly off-topic and let's return to supporting mathjax correctly.

[andreabedini]

damn, I spent the afternoon implementing this :) that's the status here? I'd love to see it merged soon!

[jamesplease]

I'm interested in helping out to get this merged. @chjj if this was rebased would you consider merging it?

[julou]

+1 for merging!

[summivox]

Quite suprised to see this attracting attention 1 year after I first wrote it.
I did rebase this quite long ago but master has advanced since then. Rebasing doesn't make any more sense if master keep going ahead without merging this in.
@chjj : would you mind giving a word on this?

[julou]

I was misled by use cases that made me think that this issue was not taken into account.
Indeed, underscores are actually protected between $.

However, curly braces introduce are another source of problem: e.g. in $\mu_{d,A} ?= \mu_{d,B}$ is rendered as $\mu<em>{d,A} ?= \mu</em>{d,B}$.
More intriguingly:

• $\mu_{d}$, $\mu_m$ parametrized by $\theta_d$ and $\theta_m$ is rendered correctly
• $\mu_d$, $\mu_{m}$ parametrized by $\theta_d$ and $\theta_m$ is rendered as $\mu<em>d$, $\mu</em>{m}$ parametrized by $\theta_d$ and $\theta_m$

I guess this should be considered as a bug.

[summivox]

@julou : I failed to reproduce the bug at 2d3594f .

coffee> marked('$\\mu_{d,A} ?= \\mu_{d,B}$')
'<p><script type="math/tex">\\mu_{d,A} ?= \\mu_{d,B}</script></p>\n'
coffee> marked('$\\mu_{d}$, $\\mu_m$ parametrized by $\\theta_d$ and $\\theta_m$')
'<p><script type="math/tex">\\mu_{d}</script>, <script type="math/tex">\\mu_m</script> parametrized by <script type="math/tex">\\theta_d</script> and <script type="math/tex">\\theta_m</script></p>\n'
coffee> marked('$\\mu_d$, $\\mu_{m}$ $\\theta_d$ and $\\theta_m$')
'<p><script type="math/tex">\\mu_d</script>, <script type="math/tex">\\mu_{m}</script> <script type="math/tex">\\theta_d</script> and <script type="math/tex">\\theta_m</script></p>\n'

[julou]

Thanks for checking!
Which version of marked.js is that?
I just forked and build chjj/marked and when I run tests, I never get <script type="math/tex">. Is there any options to add?

[summivox]

@julou : mathjax: true

[julou]

After getting in touch with summivox, it appears that his test was run using his mathjax branch which has not yet been merged to chjj's master. Hence my first comment :)

+1 for merging!

Such a widely used md parser deserves a better support for inline math…

[AaronO]

@summivox @julou I created a fork of marked called kramed (https://github.com/GitbookIO/kramed). We will be using it for GitBook.

It has your mathjax support already integrated and published on npm (release 0.4.0).

Here's Why we forked marked

[summivox]

@AaronO : Sweet. Won't close this PR for the time being though.

[rymohr]

Why introduce a new syntax when you can just piggyback on code blocks and use a custom renderer?

```latex
f(x) = \int_{-\infty}^\infty
    \hat f(\xi)\,e^{2 \pi i \xi x}
    \,d\xi
```

https://github.com/chjj/marked#overriding-renderer-methods

[summivox]

Because inline math.

[cben]

Scholdoc found a reasonable way to use backticks for inline math - require
exactly 2 backticks:
http://scholarlymarkdown.com/Scholarly-Markdown-Guide.html#inline-math
It's almost compatible with existing docs (using more than one backtick is
rare), and still allows anything to be escaped in new docs as you can
always use 3 or more backticks instead of 2.
I'm not saying that's a great syntax, just mentioning it.

If you want to compare to syntaxes others implemented, I'm cataloguing them
at https://github.com/cben/mathdown/wiki/math-in-markdown (feel free to
edit, it's a wiki).
The fragmentation is somewhat sad.
My personal opinion is that most scientists writing in markdown will
flock to pandoc so it's best to stick to one of the syntaxes that pandoc
supports.

2015-03-10 0:44 GMT+02:00 summivox notifications@github.com:

Because inline math.

—
Reply to this email directly or view it on GitHub
#180 (comment).

[summivox]

@cben : I was aware of these work. This fragmentation is unfortunate yet inevitable -- considering we actually have CommonMark now.

Very ironic -- this patch was here over 2 years ago.

[joshbruce]

Clsoing due to staleness, possibly going beyond the specifications we are focusing on, and merge conflicts. See #956