Consider separating out `Options` from `Doc` type

[tysonzero]

I am assuming the reason they are intertwined is because of the ToMarkup instance, but IMO how the markdown doc is converted to Html is not an inherent part of the markdown itself.

For my use case I will probably never actually use the ToMarkup instance, as I'm writing a custom markdown renderer on top that outputs a Miso View. So the Options will never actually be used.

When I saw the Options in the Doc I ended up just source diving to see what exactly it does, as from the surface it looks as though the markdown function itself might use it, which it basically doesn't (except for the debug flag which IMO isn't needed since Doc has a Show instance).

I think the developer experience would be nicer if Options was removed from Doc, and renderDoc was tweaked to have type Options -> Doc -> Html. As that would make it obvious that Options is not for markdown parsing or manipulating itself, but purely for outputting it to Html.

[jgm]

I don't really maintain this library any more. I suggest looking into jgm/commonmark-hs going forward.

[tysonzero]

Is commonmark-hs prod ready? It looks like it's listed as experimental and not on hackage. We need to use a pure Haskell parser as it needs to work with GHCJS, and we aren't really able to wait at all for in development ones to finish. I'm happy to help maintain cheapskate if that would help at all, it has most of what we need and I wouldn't be opposed to solving the issues I have myself.

[jgm]

It's not published yet. You could vendor it, but it may still change quite a bit before I publish it. Anyway, since I'm putting my time into that project, I'm not interested in putting time into cheapskate. And I'd be reluctant to merge a big API change like this, since it would break things for others who do use cheapskate... Maybe the best solution for you is to use a local fork.

[tysonzero]

That's fair. In that case would you be open to merging backwards compatible PR's such as the rendering stuff I was talking about? Changes like this one are not quite as important.

What is the long term status of cheapskate in that case? I can understand you not wanting to put time into it, but for the existing projects that depend on it (e.g. PureScript / our projects) would you be open to other people maintaining or co-maintaining it.

I really like the library due to it's performance and simplicity and the fact that it is pure Haskell.

[jgm]

Yeah, sure. I'd be receptive to changes that don't break things for others, and possibly to co-maintaining. Cheapskate is still really great for speed and memory usage in normal cases (much better than commonmark-hs). It has some serious parsing problems (I wish I'd documented them better; I can't remember them now). And it has nonlinear performance with many pathological inputs. It's also not commonmark-compatible. These are the things that led me to give up on it...

[tysonzero]

What flavor of markdown is cheapskate aiming to implement? I.e is there a spec that can be checked against so we know exactly when the parsing is deviating from the spec?

I'm alright with some parsing quirks and will create issues / fix them when I find them as well as any other issues I come across.

[jgm]

No spec. There weren't specs around at the time I wrote it. That was part of the motivation for the commonmark project. All you have with cheapskate is a fairly cursory test suite.