github-markdown is abandonware. Lose it or resurrect+support it?

[jdickey]

The message on the RubyGems page for github-markdown is pretty explicit:

THIS GEM IS NOT MAINTAINED AND NOT SUPPORTED. ...

That page also shows version 0.6.9, released 10 August 2015, as the most recent version, and does not show a link to a source repo. Searching on GitHub itself for anybody's fork of the repo comes up empty.

She's dead, Jim.

For those of us who freak out (or whose bosses/customers freak out) at the thought of continuing to use software that depends on abandoned (and therefore presumed insecure) components, but who love what HTML::Pipeline does for us, what's the plan going forward? DAE know of any viable alternatives?

[jdickey]

WTH?

I was just pointing out that this has been problematic for some time; the only people not worried about the security implications of their work are the folks whose users don't know they've already been hacked…

Yes, I was making a big deal about it because, for a lot of us, it is a big deal. If I were working less than 90-hour weeks on my "day" job, I'd pitch in as I have on several other projects before, but staying quiet about security threats is a good working definition of malfeasance.

Grow TF up. Or at leat provide a substantive response.

[bmikol]

While I had originally commiserated about this impending(?) problem, I decided instead to leverage a gem project I just cobbled together to run source text through Typogruby via HTML::Pipeline (called HTML::Pipeline::TypogrubyFilter, 'natch) to run Markdown source through Redcarpet instead. I just pushed the first commit, so utilize the (large?) amount of salt you see fit if you choose to use it: HTML::Pipeline::RedcarpetFilter

@jdickey, I'm inferring that you have a hefty corpus of Markdown source on your hands with which you can test - I'd be much obliged if you could give it a spin and see if it's doing what you need it to do. From my own testing, it looks like it's pretty good with two exceptions:

1. github-markdown will insert <br> after line endings that are followed by another line of text; Redcarpet does not do this by default. I need to investigate further to see if there's an option that can turn this on.
2. For some reason, it breaks HTML::Pipeline::RougeFilter. FYI if you're dependent on that for code syntax highlighting.

Lastly, this is super bare-bones at the moment - so I haven't gotten around to implementing the context hash to flip on and off all the super-sexy options Redcarpet offers. I just enabled the :autolink and :fenced_code_blocks extensions as it mirrors the github-markdown functionality.

[jdickey]

@bmikol Thanks heaps; I'll get on this in the next couple of days, but if this is working well, it would eliminate several piles of steaming crap in my own code that I'd love to ditch.

As far as github-markdown vs RedCarpet on list items, AFAICT github-markdown's behaviour violates the CommonMark spec for list behaviour, which indicates that text following a list item and not separated by an intervening empty line should be treated as content within that last list item. My guess is that CommonMark compliance would break a lot of GitHub pages that depend visually if not semantically on the newline being irrelevant. Installed base > standards, as Microsoft proved in the 1990s. I prefer (and our corpus assumes) RedCarpet (and CommonMark) as the correct behaviour in this instance.

We don't have any dependency on RougeFilter, thank $DEITY, though that does sound decidedly odd. OTOH, github-markdown is now abandonware; that quirk might have made the decision easier.

Thanks for your hard work! :clap:

[jdickey]

Following on from that last, if anyone is interested, we care about Markdown-to-HTML conversion (and HTML-to-Markdown as well, though that's another Sisyphean task entirely) less in terms of pure visual presentation per GitHub than software-driven parsing and manipulation. There's a UI component to this, of course (actually several), but being able to reliably slice and dice content that's authored in Markdown and incorporates later changes to HTML rendering of the original, that are themselves specified in Markdown, is proving an interesting challenge.

[bmikol]

Sure thing! I hope it works out - looking forward to hearing how your testing goes. Thanks for doing that.

And thanks for the details on the list item behavior. To be honest, I had no idea that CommonMark was out there; my personal Markdowning has been way more casual than your professional pursuits. I can only imagine the interesting challenges of Markdown <-> HTML you're dealing with.

[gjtorikian]

We at GitHub have now moved on to https://github.com/gjtorikian/commonmarker.

Would there be interest in a PR to support this rendering pipeline instead of github-markdown?

cc @jch

[gjtorikian]

Fixed by https://github.com/jch/html-pipeline/pull/274.