5 ms·

marked.js has a GFM option, which is what Markdown Here appears to be using: https://github.com/adam-p/markdown-here/blob/dc1454ecb26a95120a8662461c9629911dbc06

marked.js has a GFM option, which is what Markdown Here appears to be using: https://github.com/adam-p/markdown-here/blob/dc1454ecb26a95120a8662461c9629911dbc0638/src/common/markdown-render.js#L77 https://github.com/adam-p/markdown-here/blob/dc1454ecb26a951... I guess these days most projects use GitHub markdown since it's the most common and with the best documentation.

kibwen 9y ago
It's not quite so simple. Markdown's problem is that it's always been pretty ill-specified. The original GFM was merely an extension to "Markdown", with its myriad of implementations all with differing behaviors. Even the marked.js README says that it merely "more or less passes the official markdown test suite"; which tests doesn't it pass? And what official Markdown test suite is this referring to ("official" would imply that it's from John Gruber himself, but the first Google result for "official markdown test suite" doesn't have Gruber's name on it)? Of course nowadays we have CommonMark, but despite ongoing activity CM has yet to have a 1.0 release, meaning that even if one intended to adhere to CM, ongoing maintenance would be required to ensure compatibility. Given that it looks as if marked.js last had a release in mid-2015, that would lead one to assume that it's not trying to follow CM. Furthermore, it was in March of this year that GFM was officially redefined to be an extension of CommonMark, not of Markdown: https://github.github.com/gfm/ https://github.github.com/gfm/ , so it's unclear which version of GFM marked.js is emulating. Lest anyone think I'm taking this too seriously though, the project here in the OP almost certainly doesn't need to care about compatibility. The markup produced is completely transient, so the worst that would happen upon hitting an unintended edge case would just be some temporary cursing on the part of the user. Where it actually matters is when you're storing the markup long-term and expect to ever want to upgrade your Markdown parser without breaking everything; for an example of the difficulty here, see how Rust has been attempting to gracefully upgrade the parser in rustdoc for almost a year now: https://internals.rust-lang.org/t/what-to-do-about-pulldown-and-commonmark/5115 https://internals.rust-lang.org/t/what-to-do-about-pulldown-... , https://github.com/rust-lang/rust/issues/44229 https://github.com/rust-lang/rust/issues/44229

kibwen 9y ago

It's not quite so simple. Markdown's problem is that it's always been pretty ill-specified. The original GFM was merely an extension to "Markdown", with its myriad of implementations all with differing behaviors. Even the marked.js README says that it merely "more or less passes the official markdown test suite"; which tests doesn't it pass? And what official Markdown test suite is this referring to ("official" would imply that it's from John Gruber himself, but the first Google result for "official markdown test suite" doesn't have Gruber's name on it)? Of course nowadays we have CommonMark, but despite ongoing activity CM has yet to have a 1.0 release, meaning that even if one intended to adhere to CM, ongoing maintenance would be required to ensure compatibility. Given that it looks as if marked.js last had a release in mid-2015, that would lead one to assume that it's not trying to follow CM. Furthermore, it was in March of this year that GFM was officially redefined to be an extension of CommonMark, not of Markdown: https://github.github.com/gfm/ https://github.github.com/gfm/ , so it's unclear which version of GFM marked.js is emulating. Lest anyone think I'm taking this too seriously though, the project here in the OP almost certainly doesn't need to care about compatibility. The markup produced is completely transient, so the worst that would happen upon hitting an unintended edge case would just be some temporary cursing on the part of the user. Where it actually matters is when you're storing the markup long-term and expect to ever want to upgrade your Markdown parser without breaking everything; for an example of the difficulty here, see how Rust has been attempting to gracefully upgrade the parser in rustdoc for almost a year now: https://internals.rust-lang.org/t/what-to-do-about-pulldown-and-commonmark/5115 https://internals.rust-lang.org/t/what-to-do-about-pulldown-... , https://github.com/rust-lang/rust/issues/44229 https://github.com/rust-lang/rust/issues/44229