Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Math expressions #8

Closed
nournia opened this issue Apr 13, 2014 · 7 comments
Closed

Math expressions #8

nournia opened this issue Apr 13, 2014 · 7 comments

Comments

@nournia
Copy link

nournia commented Apr 13, 2014

Usage of math expressions in Markdown text is quite common. I've found this PR markedjs/marked#180 in marked which brings this feature. Main issue with current implementation occurs in cases like this:

$ A_{i} + B_{i} $

That inner part of $s must not be rendered as a normal piece of Markdown text. Actually, mentioned PR is not merged yet but I think supporting this expressions only needs exclusion of $s content. For example, output of this simple case:

$ A_{i} $

Is completely compatible with MathJax which renders that as its equivalent expression.

@lepture
Copy link
Owner

lepture commented Apr 27, 2014

My suggestion is that you write MathJax in a syntax of

```math
A_{i} + B_{i}
```

And use custom renderer to deal with this special block code.

@nournia
Copy link
Author

nournia commented Apr 27, 2014

Using $ for inline expressions and $$ for expression blocks, is quite conventional. Because, these symbols are supported in LaTeX writing. There is a discussion about those symbols in mentioned PR.

In that PR, math expressions are treated as first class ones which use their special renderer. I think this is the correct way of math expression support, and I want it to be merged. But I think introducing a simple option for preventing lexer from analyzing inner text of $ and $$ symbols, would do.

@bordaigorl
Copy link

I second adding support for math but I suggest making it independent from the backend for rendering (e.g. MathJax). This requires extending the parser and the renderer to have dedicated parse/render math methods.

Alternative renderers could embed the formulas as static images in applications where MathJax is an overkill or javascript is not allowed.

I like Pandoc's approach on syntax: http://johnmacfarlane.net/pandoc/README.html#math

The dollar sign is used, as in LaTeX, to mark an inline equation but the beginning dollar cannot be followed by spaces and the closing one cannot be preceded by spaces. This way you can use $ as the currency symbol without having the wrong parts of the text parsed as formulas.

@lepture
Copy link
Owner

lepture commented Jun 22, 2014

Here is an attempt of implementation for Math: ipython/ipython#6028

@takluyver is implementing it in IPython.

@takluyver
Copy link
Contributor

My implementation, which seems to be working so far:
https://github.com/ipython/ipython/pull/6028/files#diff-4af018b2150b49924f09637b053aa362R73

It's fairly straightforward, but it did require subclassing everything. I don't think it will handle block-context maths ($$foo$$) inside list items or footnotes, as per our discussion on #11.

Of course, I'd be very happy for this to end up integrated into mistune.

BTW, do you have an estimate for when the next release will be? Because my implementation depends on the changes in #11, we can't merge it until there's a new release of mistune so our tests can pass.

lepture added a commit that referenced this issue Jun 27, 2014
can custom the parsing process of list and footnote.

Related issues:
- #8
- #11
@lepture
Copy link
Owner

lepture commented Jun 27, 2014

@takluyver Version 0.3.0 is released.

@lepture lepture closed this as completed Aug 14, 2014
@martinosorb
Copy link

martinosorb commented Feb 23, 2021

I believe this issue is again there in mistune v2. Is there a way to avoid parsing markdown within $ and $$ equation blocks?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants