Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Math on GitHub: Following Up

nschloe.github.io

Post reply on HN
Print view View original

11–20 of 46 posts

Re: Math on GitHub: Following Up

#11

Post by remram »

nschloe wrote: post #8
throwaway71271 wrote: post #5

this feature is super garbage: `this costs 5$ but that is 8$, what do you think` is now math expression with all kinds of broken rendering i had to go and fix like 20 markdown files how can someone thing this is good syntax is beyond me.

Well, it _is_ (La)TeX syntax. With the exception that there, if you want a dollar sign, you have to type \$. But yeah, the syntax isn't made for Markdown.

I think the problem is the change. You didn't need \$ before, and now people's files are broken.

GitHub could have run their parser on a sample of existing Markdown file and check that the output doesn't change. They have such a huge corpus, with author date info, it is so easy to test that files authored before the feature don't trigger the feature.

Re: Math on GitHub: Following Up

#12

Post by nschloe »

red_admiral wrote: post #4

This sounds like a solved problem in theory, but someone has to fix the parser. The commonmark spec defines left- and right-flanking delimiters, and provides a reference implementation that can get this right for backticks to represent inline code. Doing the same with dollar signs - and treating the content delimited by them, like the content delimited by backticks, as not to be processed further as markdown should h…

I agree: If you're choosing dollar signs for your math delimiters, you can't expect them to work as regular dollar signs anymore; just like backticks.

> sounds like the parsing operations are done in the wrong order.

Indeed!

> I've used jupyter-book to typeset math-in-markdown before now,

They're using $-math as well?

Re: Math on GitHub: Following Up

#14

Post by bachmeier »

> GitHub’s current choice of syntax goes against the Markdown grain.

I don't see that at all. It's pretty common. Far more common IME than all other choices combined. The problems are caused by parsing the markdown first, then slapping on math support to what's left, and of course that doesn't work.

This really is an easy problem to solve (and has been for ages). Handle the math sections first and make math support opt-in. The Gitlab syntax is great unless you want to do something other than have Gitlab render your markdown files. That's not much of a solution.

Re: Math on GitHub: Following Up

#15

Post by woodruffw »

bachmeier wrote: post #14

> GitHub’s current choice of syntax goes against the Markdown grain. I don't see that at all. It's pretty common. Far more common IME than all other choices combined. The problems are caused by parsing the markdown first, then slapping on math support to what's left, and of course that doesn't work. This really is an easy problem to solve (and has been for ages). Handle the math sections first and make math support o…

> Handle the math sections first and make math support opt-in.

Unless I'm misunderstanding what you mean, this isn't possible in a backwards-compatible manner: It's perfectly reasonable for pre-existing Markdown to have content like "Bob pays $1 for bananas, Susan pays $2," which would mis-render a normal sentence as if it had inline math content.

The blog post author's proposal is the most reasonable one: it's both backwards-compatible (the triple-tick "math" group was not already defined or, if it was, a new unique identifier could be used) and doesn't produce any ambiguities with other parts of the Markdown grammar or non-semantic text. Finally, it avoids parser composition, which is a source of all kinds of nasty differential bugs.

Re: Math on GitHub: Following Up

#16

Post by 7x11x13 »

woodruffw wrote: post #15
bachmeier wrote: post #14

> GitHub’s current choice of syntax goes against the Markdown grain. I don't see that at all. It's pretty common. Far more common IME than all other choices combined. The problems are caused by parsing the markdown first, then slapping on math support to what's left, and of course that doesn't work. This really is an easy problem to solve (and has been for ages). Handle the math sections first and make math support o…

> Handle the math sections first and make math support opt-in. Unless I'm misunderstanding what you mean, this isn't possible in a backwards-compatible manner: It's perfectly reasonable for pre-existing Markdown to have content like "Bob pays $1 for bananas, Susan pays $2," which would mis-render a normal sentence as if it had inline math content. The blog post author's proposal is the most reasonable one: it's both…

The “opt-in” would make it backwards-compatible, since any preexisting files would have math support disabled.

Re: Math on GitHub: Following Up

#17

Post by bachmeier »

woodruffw wrote: post #15
bachmeier wrote: post #14

> GitHub’s current choice of syntax goes against the Markdown grain. I don't see that at all. It's pretty common. Far more common IME than all other choices combined. The problems are caused by parsing the markdown first, then slapping on math support to what's left, and of course that doesn't work. This really is an easy problem to solve (and has been for ages). Handle the math sections first and make math support o…

> Handle the math sections first and make math support opt-in. Unless I'm misunderstanding what you mean, this isn't possible in a backwards-compatible manner: It's perfectly reasonable for pre-existing Markdown to have content like "Bob pays $1 for bananas, Susan pays $2," which would mis-render a normal sentence as if it had inline math content. The blog post author's proposal is the most reasonable one: it's both…

> which would mis-render a normal sentence as if it had inline math content

Not if it's opt-in. If you opt in to math support, you use \$, but that's a choice you make. Also, you can force an opt-in to use dollar signs vs \[ and \(.

> The blog post author's proposal is the most reasonable one

I gave the problem with that. It's not standard syntax, so markdown parsers like Pandoc stop working. And technically, that doesn't even fix anything, because someone could have been using that syntax already. It might not be common, but it isn't a foolproof fix.

Re: Math on GitHub: Following Up

#18

Post by williamstein »

nschloe wrote: post #9
tendstofortytwo wrote: post #7

I wonder how pandoc[1] does this. You can convert Markdown to PDF (`pandoc test.md -o test.pdf`), it uses the same syntax as GitHub ($ signs only, no backticks) and it fares a lot better than GitHub in a few of the tests outlined in the article[2]. It's not perfect but clearly something better can be done. [1]: https://pandoc.org/ [2]: https://nsood.in/hn-latex/test.pdf

Probably pandoc protects whatever is inside $...$ or $$...$$. GitHub doesn't. I would be curious to know how pandoc handles the other failing cases.

There are many approaches to this problem. E.g., Jupyter notebooks implement one that has matured in the wild over a decade. There's this very flexible markdown-it plugin that implements anther https://github.com/goessner/markdown-it-texmath, and my version of it here https://github.com/sagemathinc/cocalc/blob/master/src/packag... which I rewrote in typescript with a focus on the same semantics as Jupyter has, but for CoCalc. I've also been working on using unifiedjs to provide more general latex for Markdown (not just formulas) here https://github.com/sagemathinc/cocalc/pull/5982

Parsing math in markdown is easier if you use a plugin to an existing markdown parser, rather than trying to do some hack outside of that (which is what Github probably does, and also what Jupyter does).

Re: Math on GitHub: Following Up

#19

Post by prash_ant »

The `$...$' and `$$...$$' delimiters are used in TeX. LaTeX uses the more superior delimiter as `\(...\)' and `\[...\]'.

All the MathJax and KaTeX related markdown for math should use the LaTeX delimiters and avoid the TeX delimiters.

For more info see https://docs.mathjax.org/en/v2.5-latest/tex.html#tex-and-lat...

Re: Math on GitHub: Following Up

#20

Post by idianal »

A GitHub bug I recently noticed that seems related:

Expected: When a repo's readme is named `README` (without the `.md` suffix), it is rendered as plain text. When a repo's readme is named `README.md`, it is rendered as Markdown.

Actual: When a repo's readme is named `README` (without the `.md` suffix), the presence of `$` causes parts of the file to be rendered as math. For a real-life example, see the readme in https://github.com/idianal/personal-site.

Can someone please point me where I can submit a bug report/issue for this?

Post reply on HN