4 ms·

> provide a common subset of features for all parsers to target, instead of trying to include everyone’s pet feature I'm aware. Equations aren't exactly a "pet

> provide a common subset of features for all parsers to target, instead of trying to include everyone’s pet feature I'm aware. Equations aren't exactly a "pet feature" though, unless things like code blocks are also pet features. There's an easy solution - have syntax that turns off parsing (a nowiki type syntax). Commonmark accomplishes very little if it can't be used to produce the documents people are creating. If you want to add equations, you need an extension. And if you use two extensions, you need to make sure they interact correctly. And you have to be sure that all the extensions that might possibly be used interact nicely together. At that point, you have your own version of markdown, and you need to preprocess all your commonmark documents. But yeah, it's nice that all commonmark implementations use the same syntax for bold and italics. Unfortunately writing involves a lot more than that.

oefrha 7y ago
> There's an easy solution - have syntax that turns off parsing (a nowiki type syntax). Okay, that's fair, but CommonMark standardized de facto standards -- it was born as Standard Markdown after all -- and AFAIK there's no de facto standard here, so it would be pretty dangerous for jgm to pull something out of thin air. I can see why there's reluctance here. (IIRC fenced code blocks were pretty widespread before CommonMark, and even if not, being part of GFM would almost make it a de facto standard. Note that CommonMark was a joint effort among GitHub, Stack Exchange, Reddit, etc.; SE's  solution was atrocious, so GFM fenced code block was an obvious win.) Also, code blocks with language specification is apparently of way higher importance to programmers than typeset math, so comparing the two isn't that useful. (I say this as a physicist who breathe typeset math.) Now, going back to > you can't use this together with code blocks containing $ (meaning it doesn't work for languages like PHP and R). Why do you need to typeset math within code blocks or code spans? Code blocks and code spans are verbatim by definition. Interpret $ inside code blocks and code spans as verbatim; interpret $ outside as LaTeX delimiters. Problem solved. Maybe I'm missing something.
- bachmeier 7y ago
  > Why do you need to typeset math within code blocks or code spans? The problem is that commonmark doesn't recognize math at all. If you want to use texme, you can't have code blocks that containing $. For it to work properly, you'd need a preprocessor to parse the whole file, convert equations in the text as needed but ignore text in code, output to a format that doesn't cause problems with commonmark (for instance, protecting underscores outside code blocks). At that point you are way beyond just "using commonmark". It's simply not suited for even moderately complicated documents.
masukomi 7y ago
Commonmark wasn't trying to be a "useful" or "good" version of Markdown. Commonmark was trying to nail down the specification of a _particular existing version_ of Markdown because devs weren't handling the edge cases correctly and it was problematic for users.

oefrha 7y ago

> There's an easy solution - have syntax that turns off parsing (a nowiki type syntax). Okay, that's fair, but CommonMark standardized de facto standards -- it was born as Standard Markdown after all -- and AFAIK there's no de facto standard here, so it would be pretty dangerous for jgm to pull something out of thin air. I can see why there's reluctance here. (IIRC fenced code blocks were pretty widespread before CommonMark, and even if not, being part of GFM would almost make it a de facto standard. Note that CommonMark was a joint effort among GitHub, Stack Exchange, Reddit, etc.; SE's  solution was atrocious, so GFM fenced code block was an obvious win.) Also, code blocks with language specification is apparently of way higher importance to programmers than typeset math, so comparing the two isn't that useful. (I say this as a physicist who breathe typeset math.) Now, going back to > you can't use this together with code blocks containing $ (meaning it doesn't work for languages like PHP and R). Why do you need to typeset math within code blocks or code spans? Code blocks and code spans are verbatim by definition. Interpret $ inside code blocks and code spans as verbatim; interpret $ outside as LaTeX delimiters. Problem solved. Maybe I'm missing something.

bachmeier 7y ago
> Why do you need to typeset math within code blocks or code spans? The problem is that commonmark doesn't recognize math at all. If you want to use texme, you can't have code blocks that containing $. For it to work properly, you'd need a preprocessor to parse the whole file, convert equations in the text as needed but ignore text in code, output to a format that doesn't cause problems with commonmark (for instance, protecting underscores outside code blocks). At that point you are way beyond just "using commonmark". It's simply not suited for even moderately complicated documents.

masukomi 7y ago

Commonmark wasn't trying to be a "useful" or "good" version of Markdown. Commonmark was trying to nail down the specification of a _particular existing version_ of Markdown because devs weren't handling the edge cases correctly and it was problematic for users.