Hacker News Reader

Comment by nerdponx | Hacker News Reader

I wonder if Pandoc being written in Haskell is what's stopping it from being the default Markdown engine everywhere. Or am I misunderstanding the technical needs here?

View on HN

I tried to switch from markdown.pl to Pandoc and encountered some problems, one of which remains an open issue (https://github.com/jgm/pandoc/issues/1841): https://twitter.com/arntzenius/status/745946799836381184

A telling comment on that github issue is "Actually, it's a bit unclear what the behavior should be." I think the real problem is the idea of "a default Markdown engine" is pretty impossible when Markdown doesn't even have a formal spec. Complex human-readable formats without a spec are never gonna be compatible between different implementations without extraordinary effort. (Hence the http://commonmark.org/ effort, which I applaud, but doesn't seem to have a 1.0 spec out yet.)

That's sort of convincing me that Markdown + arbitrary HTML is a fundamentally unstable idea. What's the use case for it? GitHub allows a subset of HTML tags; sites like Reddit allow none.

I mean, I use Pelican's Markdown support in my own blog, but I wouldn't be unhappy about having to use <i> instead of underscores.

I use markdown for writing blog posts, and I need arbitrary HTML all the time. For tables; or for custom syntax highlighting; for drop-down menus that let readers choose what PL they want to see examples in (http://www.rntz.net/post/2016-06-06-not-everything-is-an-exp... ); to put the numbers on section headings into the left-margin; etc, etc.

Basically, markdown has (at least) two use-cases:

1. A safe (if you do HTML sanitization properly) way to let people mark-up their input on web comment sites like HN, StackOverflow, etc. This is probably the most common use-case.

2. A web authoring tool. This was the intended use-case.

Supporting arbitrary HTML is absolutely inadmissible for (1); not having arbitrary HTML is basically inexcusable for (2). And yeah, I could write the posts in straight HTML, but honestly that's a pain. Why shouldn't there be a tool that makes writing styled-text-with-lists-and-headings easy but lets me drop down to HTML when I need to?

Because intermixing Markdown and HTML is ambiguous, and if you're authoring HTML, you clearly know HTML already?

I'm not actually sure I believe this yet. But I think I'd see a lot more use case for something that lets me do a very tiny amount of things, maybe just headings and bold and italic, and avoids not only ambiguity but any risk of ambiguity.

It just feels like we've reinvented HoTMetaL (https://support.novell.com/techcenter/articles/img/ana199609...) but with bonus ambiguity.

Are you saying you shouldn't use HTML with markdown? Markdown was explicitly designed not to cover each and everything HTML, and so that you could fallback to HTML; it's kind of the entire point of markdown (or have I misunderstood you?).

> But I think I'd see a lot more use case for something that lets me do a very tiny amount of things, maybe just headings and bold and italic, and avoids not only ambiguity but any risk of ambiguity.

When you build that, let me know. Until then I'll be over here, using a Perl script from 2004 that still works just fine.

There's an easy compromise between (1) and (2): configurable bleaching.

I also use markdown for writing blog posts, and have a lot of the same pain points. I have been working on an extended version of markdown (https://github.com/alexbecker/blogdown) to fix this.

AFAIK the author of Pandoc is also a CommonMark core contributor.

Pandoc isn't used by this VSCode plugin, so I'm not sure why that's relevant? Generating a PDF from Pandoc depends on LaTeX, which is over 2GB. Definitely not a solution for "everywhere".

Also there are some arguably nicer alternatives to just shoving LaTeX syntax into markdown, for example http://asciimath.org.

LaTeX itself isn't over 2GB. The complete texlive distribution is about that large, but that's everything and the kitchen sink.

You can install a small base which comes in ~150mb, then add packages as you need.

and then 90 seconds later you'll find yourself running `sudo apt-get texlive-full` because some mysterious font somewhere is wedging up the gears and it's not worth sorting out.

Yeah, fair enough. On MacTeX or texlive on Arch, it usually takes me a few iterations of `tlmgr install` runs before I have everything I need. "collection-fontsrecommended" is usually the (meta) package I install these days.

I wish texlive would move to rolling updates, or at-least make distribution upgrades easier.

Arg, this reads like LaTeX without the backslashes and with minor inconsistencies. Why not just use a proper subset of LaTeX math notation instead of inventing yet another syntax?

Because, sometime you don't need all the whistles, but only a subset.

Curious, what inconsistencies does asciimath have?

Probably for the same reason that we don't create modern programming languages using a subset of FORTRAN syntax: because we can do better.

Note that one of the advantages of asciimath is that it maps unambiguously to MathML.

Reply on news.ycombinator.com