New Code!
Markdown has been pushed up to version 0.8 after a few days of fairly massive tweaking. After I released 0.7.5 I went back and started thinking about how to do the markup for definition lists, and while I was thinking about it I thought of many other things that I wanted to get done.
The final code contained some fairly extensive changes:
- markup for definition lists is now supported, if enabled
during configuration with the
--with-dl-tagoption. The new markup is ^=tag=$, with the list item – indented at least 4 spaces – beginning on the very next line. - start writing public interfaces to get at some of the internals in the code.
- a sample “mkd2html” program that demonstrates the (still unfinished) internal interfaces.
- correct the order of
<code>and<pre>in code blocks. - properly inherit from the parent frame in
reparse() - add a parse tree dumper (
dumptree()) and modify themarkdownprogram to use it when passed the-dflag. - Rip
markdown.cin half; one half is the backend html generator, the other half is the tree builder. - change
mkd_text()andmarkdown()to returnint - write a manpage for
markdown(1). - completely rework the way whitespace is handled. It is now a paragraph separator, not a terminator.
- configuration cleanups to make it happier on more platforms.
The big new thing in markdown is, of course, the addition of definition tags. They need to be turned on when the package is configured (the --with-dl-tag option,) but once turned on are always available.
A definition list is =label= list item indented 4 spaces.
which produces the output
The label is treated as regular markdown text, so you can put images and links into the label. My home page (markdown source) wants this, because I want the labels to be the links and the descriptive text to just be descriptive text.
I’ve started pulling some of the internal functions out into the open, so I can get access to data structures during the compilation (I plan to make the footnotes list acessable, so I could do things like check the validity of footnotes before generating the output page, rewrite nonexistant local links to point at edit pages, and *poof* I’d have a wiki.) I’ve written a little demo program to demonstrate how this will work, even though the interfaces are still very fluid and will most likely change before the 1.0 release rolls down the pike, and I’ve expanded the markdown program (documented!) so that it can do a parse tree dump showing the structure of the input as markdown sees it.
I don’t think it’s ticking, but even with the possibility of it not being a catastrophic release it’s still good enough to be New Code!, and now I can turn around and aim my malign gaze in the direction of the horrible weblog program that’s had markdown wedged so inelegantly into it.