In 4-space indented code blocks (see my previous issue about lack of support for ``` code blocks), _ expands to or as appropriate. It would be nice if this didn't happen.

Need to find a way to not mess with inline/inline-block elements.

Hi,

I was trying out wookie, wookie-docs and markdown.cl and came across
this bug. Trying to parse a file with this content with markdown.cl:parse

Wookie's core plugins provide simple support for many things an
HTTP/app server...

<pre><code class="lisp">
(defun set-cookie (response key val &key expires max-age path domain http-only secure))
  => nil</code></pre>

Let's set a login cookie that expires in one day:

<pre><code class="lisp"> ;; error! </code></pre>

you'll get an "unable to resolve entity" error thrown by xmls. (Recognize the source,
btw?)

Well, I narrowed it down to the semicolongs in lisp code blocks following ampersands in other lisp code blocks. I'm not familiar enough with your parsing technique to fix it myself.

PS: wookie and the related projects seem very interesting, I am just
curious as to why you don't use cl-markdown for this. Is it because it
is sort of abandoned?

I had to do some stuff to get
tags working right, its probably no different with inline tags

There are three Common Lisp Markdown parsers. There's 3bmd, which is the
most used because it Just Works, but it's inefficient in both time and
space. Then there's cl-markdown, which was last updated in 2010.

And then there's this one, which to me shows the most promise to become the one
Markdown parser in CL, since it has a good number of tests and the code is
fairly clean and well documented.

CommonDoc is a framework for representing documents. It's basically a set
of classes that make up the internal representation of software like Pandoc, and
my goal is to build something like that.

So, the idea is to make markdown.cl emit CommonDoc documents instead of HTML,
and then those nodes can be converted to any other format.

Right now, the only working input format for CommonDoc is VerTeX, a
language with TeX syntax, and the only emitter is for HTML, so adding support
for the most common markup format would be pretty huge, and I don't want to
duplicate effort by writing yet another parser -- it hurts
consolidation.

My main goal for the CommonDoc project is to build a documentation system like
Sphinx, but in CL and especifically tuned for the needs of CL projects.

So, what do you think?

Should be easy to fix in html.lisp

How about supporting triple-backticks for marking code blocks? Thanks!

This breaks the HTML parser:

<ul>
    <li>
        <script type="text/javascript" data-name="test"></script>
   </li>
</ul>

Just checking to see whether you have given any thought to adding support for the defacto addtion of tables to markdown?

<div class="button-row">
    <!--
    <div class="button huge firefox">
        <a href="/download/firefox-latest.xpi">
            <h2>Turtl <em>v0.1.0</em></h2>
            <small>(Firefox >= 21)</small>
        </a>
    </div>
    -->
    <div class="button huge chrome">
        <a href="/download/chrome-latest.crx">
            <h2>Turtl <em>v0.1.9</em></h2>
            <small>(Chrome >= 28)</small>
        </a>
    </div>
</div>

<img src="my-image.jpg">

<div class=\"twitter\">
<a class=\"twitter-timeline\" data-dnt=\"true\" href=\"https://twitter.com/turtlapp\"  data-widget-id=\"382037759679934465\">Tweets by @turtlapp</a>
<script>!function(d,s,id){var js,fjs=d.getElementsByTagName(s)[0],p=/^http:/.test(d.location)?'http':'https';if(!d.getElementById(id)){js=d.createElement(s);js.id=id;js.src=p+\"://platform.twitter.com/widgets.js\";fjs.parentNode.insertBefore(js,fjs);}}(document,\"script\",\"twitter-wjs\");</script>
</div>

Note that XMLS tends to mangle <a> tags with no body:

<a id="asdf"></a>

...think of more (things that have been issues in the past)

Hi Andrew,

another nice library from you - so also thanks for that one.

Running sbcl w/ full debug info gave me in "unreachable code" note in parse-list-blocks, and I think this could be fixed easily:

In this function, you're returning with (unless list-pos ...), so list-pos is never nil after that. At the end of the function, you're returning a cond result for either (and list-pos (<= list-pos 1)) or list-pos or t.

Since a nil value for list-pos cannot happen here anyway, the 1st cond can be simplified to (<= list-pos 1). Doing that the check is now for list-pos either be less or equal than 1 or anything else except nil, which is already exhaustive, so that the t cond section could be removed. Doing that cleared the note with my compiler settings.

HTH, Frank