Commarkk: going backwards
At the start of the week I had a version of commarkk that would do block parsing and generate an HTML file from the document stream. I was writing the inline parser. Now none of them work!
Actually, the block parser is still working, but suffers from a serious issue. I noticed one test, which opend a list item in a deeply nested blockquote, was failing:
> > > * List item
That one failure led to re-thinking the following:
- How parsing of blockquotes, definition lists, and footnotes would work, given that all of these block types can contain pretty much any block type
- How the document parse stream should handle stacked blockquotes
- How opening multi-entry items in the document stream should work (I created a new DS_TYPE called ‘open’ and plan to use it a fair bit)
- How best to add a paragraph after a blockquote, given that a blockquote
doesn’t necessarily open a paragraph (it chould open a new blockquote, or a
list, or a table, etc) AND paragraphs are handled in a “short-circuit” fashion
in the mainline to avoid having to run the
_close_blocks
and_open_block
routines, which I consider “expensive” in terms of the time required to run them.
Then I noticed the parse_link
routine was getting uncomfortably large and
made plans to break it into a series of routines that handle different parts
of a Markdown link. When I started looking into this, I discovered
MultiMarkdown
and changed the syntax of abbreviation and glossary links between versions 5 and
6! That meant I had to review all the documentation for both versions to see if
anything else had changed.
All of that led to a complete re-analysis of how entries in the %$links
hash
are set up. That occupied the better part of two days.
This week also had a fair number interruptions. Tuesday I went to a meeting of the Manitoba Unix User Group; Wednesday had a brief interruption when I went to assist Leuba and Brian with their iPhones but they weren’t home, Thursday I met with Eryn for lunch, then attended a Winnipeg PC User Group meeting.