<p>Hi everyone, I'm a new-ish adept of Go lang, and I'm not yet very familiar with the ecosystem.</p>
<p>I want to ask if anyone knows of a markdown parser library which can be extended to include custom syntax. Thank you.</p>
<hr/>**评论：**<br/><br/>Emacs24: <pre><p>They are all shitty, although <a href="https://github.com/golang-commonmark/markdown" rel="nofollow">https://github.com/golang-commonmark/markdown</a> does look like relatively easily expandable.</p>
<p>The most popular is <a href="https://github.com/russross/blackfriday" rel="nofollow">https://github.com/russross/blackfriday</a> but looking at <a href="https://sourcegraph.com/github.com/russross/blackfriday@6d1ef893fcb01b4f50cb6e57ed7df3e2e627b6b2/-/blob/markdown.go#L32:2$references" rel="nofollow">this</a> I doubt if it is easily expandable</p>
<p>And don't waste your time on this piece of crap: <a href="https://github.com/a8m/mark" rel="nofollow">https://github.com/a8m/mark</a></p></pre>habarnam: <pre><p>Thank you. Blackfriday sounds somewhat familiar so maybe I toyed with it a while back. :)</p></pre>bear1728: <pre><p>I actually wrote one in Typescript based off Khan academy's "simple-markdown" in Javascript:</p>
<p><a href="https://gitlab.com/whatwhathuhhuh/bear-markdown" rel="nofollow">https://gitlab.com/whatwhathuhhuh/bear-markdown</a></p>
<p>I bet it would be pretty easy to rewrite it in Go since it's mostly just a few regular expressions. Of course it would take more time than using one of the others mentioned here, but if you want to learn more about parsing/markdown/go/typescript it could be an interesting project.</p></pre>habarnam: <pre><p>Thank you, but I'm already working on implementing a parser of my own, though I'm using a different approach. :)</p>
<p>I was looking for a usable solution until I manage to get mine up to CommonMark compliance.</p></pre>jerf: <pre><p>Ah, that clarifies a lot.</p>
<p>Are you looking to do a one-off extension of the syntax, or are you looking to offer a library that allows users to extend the syntax?</p>
<p>Either way, I suspect you'll find that the blackfriday library is basically the bare minimum you're going to get to support CommonMark. The standard betrays its origins and it's more complicated than an implementation of Markdown written to be clear from the get go (rather than try to harmonize multiple existing code bases) would have been.</p>
<p>If you're trying to offer the latter, you're going to find that, yeah, it's actually going to be quite the challenge. What seems to a user to be "look, I just want to add a |_ _| pair that means to wrap this bit of text in a span that puts a box around it" interacts with all the rest of the grammar; what does <code>hello |_ world *how _| are* you</code> mean? Either you hard-code answers to that question into the new extension, or you are going to eventually find yourself backed into an interface where the grammar-extending function they have to implement is basically</p>
<pre><code>type Extender interface {
Extend(p MarkdownParseTree) MarkdownParseTree
}
</code></pre>
<p>, and you just wash your hands of the consequences after that. (And I hope your Markdown nodes are themselves an interface that can be externally implemented. I'm not looking at blackfriday for this; too much work for a reddit post :) )</p></pre>habarnam: <pre><p>Thanx for the input, you make some good points.</p>
<p>To be completely honest my effort is not too tied into golang, but I need it as a golang library to extend an existing product. </p>
<p>The actual parsing I'm trying to do is using ragel - the go part is just manipulating the resulting AST, but like you said, markdown is quite complicated - and "not regular enough" - for it to work with the naive approach I'm using. I have parts of the standard working independently, but as soon as I combine them, the results are unpredictable. :)</p>
<p>Because the actual parser logic is using ragel instead of go, the library wouldn't be extendable per se, but the state machines a ragel document is composed of, can be extended easily enough, as long as they play nice as part of the whole, which is not yet the case.</p>
<p>I suspect I need to break the parsing down into stages, but this would mostly invalidate the advantage of using ragel - which would be a "one pass" parsing.</p></pre>jerf: <pre><p>Well, I can encourage you in the sense that, as far as I know, this problem just really stinks. You're not missing out on anything or something; it just really stinks.</p>
<p>Definitely steal as much of the test suite from one of the existing parsers as you can. I recognize that is easier said than done, but it might still be worth it even so, because it's just impossible to work with building a parser without a solid test suite.</p></pre>habarnam: <pre><blockquote>
<p>Definitely steal as much of the test suite from one of the existing parsers as you can.</p>
</blockquote>
<p>Yes, I will do that, I was thinking about the same thing. I have a couple of tests, but the more the better. :)</p></pre>
