Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
The Markdown Pickle #5124
So, I've been waiting for Go 1.11/Go Modules to do the Blackfriday v2 upgrade (for versioning reasons). In the meantime, things have changed on the Go markdown scene.
The motivation behind the
So, not using the new
What you describe sounds like a pretty hard dilemma.
But here is something that also needs to be taken into account besides the performance issue:
A casual search for
Disclaimer: I'm not using
Thank you for your thorough investigation!
I read through the relevant issue and could empathize with both sides of the discussion.
I am also interested in how migrating to the new
I am glad that other people like miekg and moorereason chimed-in in that issue to hopefully help move the discussion forward. And I could only wish... maybe some other kind souls could help optimize the
Today, a new idea came into me: there might be yet another alternative, and that is to have Hugo support for all three of the following:
And, of course, let Blackfriday v2 be the default. The end user can specify the other two if they don't mind the performance degradation, as for some people, a richer Markdown syntax, e.g. that closer to CommonMark. This will bloat the Hugo executable a little bit, but not by much.
Perhaps by then people could see the performance degredation with Gomarkdown/markdown fork in real-life, and might spur the main author of the
When I looked at some of the Hugo code years ago, I had a feeling that it was somewhat coupled to Blackfriday, as in when spf13 originally worked on Hugo, Blackfriday was the only supported Markdown renderer, and several functions with the name "Markdown" were actually Blackfriday specific. Though of course, the code has gone through many revisions and refactoring since then, and is already accommodating alternative renderers.
Anyhow, the integration of kjk's
That said, the new Blackfriday fork calling itself
In summary, my suggestion is to do the following in due time:
So, to me, that would be the best of both worlds, giving the end user choices, and allowing Blackfriday v2 and the
Indeed, there is some cost in maintenance for yet another Markdown renderer (3 instead of 2), but hopefully the cost isn't too much.
My 2 cents. :-)
I suspect you're not really aware of the implementation and maintenance cost of what you're suggesting.
My plan is to integrate Blackfriday v2 and use their AST to eventually do all sorts of cool stuff (starting with improved ToC support etc.). People would eventually expect to have a similar experience for Mmark and "Blackfriday Classic", but there is no way we're maintaining the above++ across two different BF forks.
The big dill is that BFv2 is largely unmaintained, but I don't see any signs of that changing.
If the performance of gomarkdown was on par with BFv2, would you move to gomarkdown? If so, I'd give gomarkdown a little time (2wks?) to reconsider the performance-killing design decision that was made. If not, then let's go to BFv2 and move on.
None of us wants to drop support for mmark. That would be unfortunate if it comes to that.
@lpar, I like your suggestion too. That said, as @ bep suggested earlier in this thread, there will be a significant implementation and maintenance cost involved with supporting multiple Markdown renderers in Hugo, so please don't be disappointed if the CommonMark Go implementation at https://gitlab.com/golang-commonmark doesn't get into Hugo.
But yeah, anything could happen in the future, e.g. Blackfriday may eventually gain support for CommonMark Go too. Let's keep our fingers crossed. ;-)
Any update or resolution of this? I hit this bug/issue in a roundabout way. I can provide my tale of woe if anyone is interested, but essentially blackfriday, pandoc, and mmark all fail me in one way or another, whereas the new mmark (or I guess, gomarkdown/markdown) work for me. I need
the new mmark processor (not the old library) does everything I need, but isn't a library...