[ann] CommonMark-compliant markdown parser and renderer

<p><a href="https://github.com/opennota/markdown">https://github.com/opennota/markdown</a></p> <p>The CommonMark v0.19 test suite completely passes, except for some inessential details related to URL encoding and such.</p> <p>The easiest way to see it in action is to use <a href="https://github.com/opennota/mdtool">mdtool</a>, an example command-line tool. Install it:</p> <pre><code>go get github.com/opennota/mdtool </code></pre> <p>and execute the following command:</p> <pre><code>mdtool +l +ta +ty https://github.com/opennota/markdown/raw/master/README.md </code></pre> <p>to render the opennota/markdown&#39;s README.md.</p> <p>Or, if you want to see the output in a browser:</p> <pre><code>mdtool +l +ta +ty https://github.com/opennota/markdown/raw/master/README.md browser: </code></pre> <p>Some benchmarks from the README:</p> <blockquote> <p>Rendering spec/spec-0.19.txt on a Intel(R) Core(TM) i5-2400 CPU @ 3.10GHz</p> <pre><code>BenchmarkRenderSpec019NoHTML 200 6116606 ns/op 2921682 B/op 7929 allocs/op BenchmarkRenderSpec019 100 15744611 &gt; ns/op 4851484 B/op 41032 allocs/op BenchmarkRenderSpecBlackFriday 200 7450171 ns/op 2722858 B/op 36689 allocs/op </code></pre> </blockquote> <p>You can notice a deplorable degradation of performance when raw HTML is enabled (it is disabled by default). Not that I will ever use this option in production, but that&#39;s sad anyway. I haven&#39;t yet identified the bottleneck (can be just a sheer number of tokens created - 5857 vs 1107 with disabled HTML). Any help will be appreciated.</p> <p>And in conclusion, some side projects written for opennota/markdown:</p> <p><a href="https://github.com/opennota/wd">https://github.com/opennota/wd</a> - compares strings on a word per word basis and generates a coloured diff for your terminal (looks like this: <a href="http://i.imgur.com/zdSsJ3O.png">http://i.imgur.com/zdSsJ3O.png</a>)</p> <p><a href="https://github.com/opennota/linkify">https://github.com/opennota/linkify</a> - finds what looks like links in plain text. Needs testing in the real world.</p> <hr/>**评论：**<br/><br/>xojoc0: <pre><p>Nice work!</p></pre>koffiezet: <pre><p>A bunch of rather cool projects, I&#39;ll surely check them out! :)</p></pre>mT5nKbHe: <pre><p>I was excited until I saw the GPL license. Please consider something more permissive. </p></pre>opennota: <pre><p>I need a compelling reason to change the license. And (just in case) &#34;Hey, I want to use this code in my proprietary closed-source software!&#34; isn&#39;t one of them. If it is, however, a MIT/BSD/whatever-licensed open-source project, I&#39;d like to hear what prevents you from using it together with GPL-licensed code.</p></pre>kjk: <pre><p>If someone picked a permissive license (MIT/BSD) for their project (as opposed to GPL), they probably did that for a reason.</p> <p>Including a GPL library would effectively change the license of the project to GPL, as GPL imposes more restrictions and those restrictions apply to combined work.</p> <p>This is why libraries are often licensed with a permissive license (I doubt you&#39;ll find any other markdown parser library with GPL) - GPL license is unacceptable not only for commercial projects but also for projects that want to use more permissive license.</p> <p>Even FSF recognizes this which is why LGPL license exists and is designed to limit the reciprocity requirements to just the component licensed under LGPL and not the combined work. </p> <p>However, due to how LGPL is defined, it can only be used if you can separate the component into its own dynamic library and Go doesn&#39;t have that (at least not yet), so LGPL is effectively equivalent to GPL.</p></pre>