Render inline math blocks as inline math

[leipert]

If I have multiple ```backticks``` inline, it will be rendered as `inline code`.
Math should also $$x+y$$ work that way.

If I have multiple backticks inline, it will be rendered as inline code.

[runarberg]

This one is difficult. Unlike fences we allow arbitrary delimiters. With latex style delimiters expressions like \(\(int) 42.2\) become impossible. Perhaps we should allow this when using a single character matching inline delimiters (inlineOpen === inlineClose && inlineOpen.length === 1). @leipert what do you think?

[leipert]

Mhm. I do not understand your example, how do you want the \(\(int) 42.2\) to be rendered?

I have the following document:

Inline Math should work with `$`  $\frac{x+y}{y}$
and `\(` \(\frac{x+y}{y}\)

Use `\[` on separate lines:

\[
\int_{-\infty}^\infty e^{-x^2} = \sqrt{\pi}
\]


Use `\[` on the same line:

\[ \frac{-b \pm \sqrt{b^2-4ac}}{2a} \]

Use `$$` on separate lines:

$$
a+b
$$

Use `$$` on the same line:

$$E=mc^2$$

And I expect it to render like this:

but it gets rendered like this:

[leipert]

This is how markdown-it-math is configured for the results above:
https://github.com/Galadirith/markdown-preview-plus/blob/master/lib/markdown-it-helper.coffee#L6-L23

[runarberg]

The reason multiple backticks renders to an inline code-span is to allow placing a literal backtick inside the code-span without closing it f.x. ` gives ``` (see here). For this to work we also need to strip initial and trailing whitespace, and that contradicts #9. It could be beneficial if you want to place a literal $ inside an inline math end-delimited also with `$` but then again we would have to sacrifice #9. This is b.t.w. precisely the reason I picked `$$` as the default inline deliminator and `$$$` as the default block deliminator.

[runarberg]

Regarding the \(\(int) 42\) statement. We also allow different parsers/renderers. Not all math is written in TeX. I first wrote this as a wrapper around my Ascii2MathML parser, which takes a derivation of AsciiMath and returns a MathML string. In Ascii2MathML \(...) forces an operator so \(int) 42.2 yields the markup <mo>int</mo> <mn>42.2</mn>.

But as I'm writing this I kind of realize that perhaps this is a non-issue. If you are writing with weird parser you should configure the deliminators accordingly. So I think I'll implement this feature request. But note that we won't be able to make inline math behave like a code-span and emphasis at the same time.

[leipert]

Maybe I miscommunicated:

I just want to render

$$$1+1 = 2$$$

like

$$$
1+1 = 2
$$$

Sorry for the misunderstanding. I just added a PR #10 for this behaviour.

[runarberg]

And regarding the failed parsing of the syntax checking document. That failed because of an unimplemented feature request, namely single line block expressions.

I wasn't sure whether we should allow block math to accept arguments, like a code fence does. It would be handy if you are writing in multiple languages to be able to pass arguments to the parser that this block should be rendered with a right-to-left directionality, and that block uses comma as a decimal mark, etc. But if we accept arguments to a block math than we sacrifice single line block math

[leipert]

The acceptance of block math arguments could be a configurable option, right?

[runarberg]

Closing and opening #11 instead.