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

Math on GitHub: The Good, the Bad and the Ugly

nschloe.github.io

Post reply on HN
Print view View original

41–50 of 71 posts

Re: Math on GitHub: The Good, the Bad and the Ugly

#41

Post by anonydsfsfs »

throwaway981572 wrote: post #24

I’m very happy they went with simple $..$ and $$…..$$ This is much more natural for anyone doing math or science and also makes it easy to copy and paste math from elsewhere It’s better that the parser works harder than to force an inconvenient syntax on the user.

The problem with adding so much complexity to the parser is that it's now impossible to predict how any given Markdown is going to render on Github. If Github's parser was open-source, you could at least look at the source to figure out this stuff is handled, but it isn't, so the only alternative is tedious experimentation.

One of the main draws of Markdown was that it was so simple you were rarely left guessing how any given input would be handled (though the lack of standardization hampered that).

Re: Math on GitHub: The Good, the Bad and the Ugly

#43

Post by JadeNB »

runarberg wrote: post #37
IshKebab wrote: post #35

Earlier quoted context omitted.

That doesn't work because then how do you display $a$ as literal inline code?

What about: Inline code is ` $a$ ` automatically trimmed But I think $`a+b`$ makes more sense (or even $$a+b$$; I mean this is markdown after all, not LaTeX).

> But I think $`a+b`$ makes more sense (or even $$a+b$$; I mean this is markdown after all, not LaTeX).

True, but it is TeX notation, and `$$ $$` for inline math goes deeply against the experienced TeXnician's intuition. Why intentionally use notation that violates some users' domain intuition when there's an alternative that's no worse?

Re: Math on GitHub: The Good, the Bad and the Ugly

#44

Post by JadeNB »

thaumasiotes wrote: post #4

> advantages of KaTeX: > It’s faster. > You can copy-and-paste math. Someone mentioned that you can theoretically copy-and-paste KaTeX output in an earlier thread about GitHub's new math rendering too. But I think calling that an "advantage" is crazy. LaTeX will transform your one-dimensional textual formula specification into a two-dimensional graphical formula. The concept of copying and pasting the output as text…

> \f\relax{x}

I know it's not your point, and the design choice is KaTeX's, not yours, but making a macro that has to be invoked as `\f\relax{x}` to substitute for `f(x)` is … kind of crazy.

(Of course, in regular TeX, at least, you could do `\f\relax x`, saving one token at the expense of looking even less like a function invocation.)

Re: Math on GitHub: The Good, the Bad and the Ugly

#45

Post by enw »

rectang wrote: post #20
edflsafoiewq wrote: post #18

Earlier quoted context omitted.

Small font size seems the easiest to fix. Kerning seems worse since people will manually tweak spacing with \, etc, so you can't just change it whenever you want.

I agree that kerning is also a problem, and I also agree that it it can't practically be fixed. However, even if it's theoretically possible to change the font size, would Github ever do so? My impression is that as an organization they place a high value on interface stability. Very little about how I interact with the site has ever changed. I suppose that individual publishers might stick in a hack to increase the…

> Very little about how I interact with the site has ever changed.

GitHub tunes the UI all the time.

Re: Math on GitHub: The Good, the Bad and the Ugly

#46

Post by colejohnson66 »

anonydsfsfs wrote: post #41
throwaway981572 wrote: post #24

I’m very happy they went with simple $..$ and $$…..$$ This is much more natural for anyone doing math or science and also makes it easy to copy and paste math from elsewhere It’s better that the parser works harder than to force an inconvenient syntax on the user.

The problem with adding so much complexity to the parser is that it's now impossible to predict how any given Markdown is going to render on Github. If Github's parser was open-source, you could at least look at the source to figure out this stuff is handled, but it isn't, so the only alternative is tedious experimentation. One of the main draws of Markdown was that it was so simple you were rarely left guessing how…

It’s simplicity is also it’s crutch. It lacks so many niche things (like math) that every implementation have their own syntax.

Re: Math on GitHub: The Good, the Bad and the Ugly

#47

Post by thaumasiotes »

JadeNB wrote: post #44
thaumasiotes wrote: post #4

> advantages of KaTeX: > It’s faster. > You can copy-and-paste math. Someone mentioned that you can theoretically copy-and-paste KaTeX output in an earlier thread about GitHub's new math rendering too. But I think calling that an "advantage" is crazy. LaTeX will transform your one-dimensional textual formula specification into a two-dimensional graphical formula. The concept of copying and pasting the output as text…

> \f\relax{x} I know it's not your point, and the design choice is KaTeX's, not yours, but making a macro that has to be invoked as `\f\relax{x}` to substitute for `f(x)` is … kind of crazy. (Of course, in regular TeX, at least, you could do `\f\relax x`, saving one token at the expense of looking even less like a function invocation.)

`f(x)` works just fine. As far as I can see, the entire point of their \f macro is to let you write `\f\hat x` instead of `\hat{f}(x)`.

Leaving aside whether that's a good idea, it's not at all clear why the example then goes on to use `\f\relax{x}` to display a function with no diacritic in its name. The diacritic was the only reason to use \f in the first place. And the advertised definition, `#1f(#2)`, doesn't only require \relax when you want to omit a diacritic. It also prevents you from doing perfectly normal things like `f\left( something-hairy \right)`.

Re: Math on GitHub: The Good, the Bad and the Ugly

#48

Post by edflsafoiewq »

nvrspyx wrote: post #39
auggierose wrote: post #25

Earlier quoted context omitted.

Given that the main point of using LaTeX in Markdown is familiarity of users, using $ and $$ is actually the ONLY proper choice. But yeah, it leads to problems, which is why I would not use Markdown in the first place, but some Markdown inspired format which mixes better with $ and $$.

This is why I prefer AsciiDoc. It's consistent because there's only one implementation, it's less ambiguous, and more predictable. Although it takes a bit longer to remember all the syntax, it's not difficult, especially if you're only going to use the same subset of features that markdown supports since it supports most of the markdown syntax as well. I also much prefer the flexibility with tables compared to markdo…

Looks crazy verbose compared to $ and $$, especially if you're actually using it intensively.
Post reply on HN