ANN: pandoc 1.3

[John MacFarlane]

I'm pleased to announce the release of pandoc 1.3, now available
for download from pandoc's google code site or from HackageDB.

In addition to fixing many bugs, this version adds the following
features:

* New --id-prefix option to help prevent duplicate identifiers
when you're generating HTML fragments.
* New --indented-code-classes option, which specifies default
highlighting syntax for indented code blocks.
* --number-sections now affects HTML output.
* Improved syntax for markdown definition lists. (See README
for a full description.)
* Better looking simple tables.
* Markdown tables without headers are now possible. (See
README for details.)
* New hard line break syntax: backslash followed by newline.
* Improved performance of markdown reader by ~10% by eliminating
the need for a separate parsing pass for notes.
* Improved syntax highlighting for literate Haskell.
* Support for "..code-block" directive in RST reader.
* Windows binary now includes highlighting support.
* Many bug fixes and small improvements. See changelog for details.

Thanks to everyone who reported bugs, and especially to buttock, who
contributed the patch for the --indented-code-classes option, and Luke
Plant, who contributed the patch for rST "..code-block" directives.

John

[John MacFarlane]

> * Improved syntax for markdown definition lists. (See README
> for a full description.)

Let me say a bit more about this, since it is the one potentially breaking
change (and the reason we went from 1.2.x to 1.3):

I wanted to make the definition list syntax more compatible with that of
PHP Markdown Extra. It's still not 100% compatible, because pandoc doesn't
allow multiple terms in a definition. But all PHP Markdown Extra definition
lists that don't contain multiple terms in a single definition should
work in pandoc now.

Previously, pandoc's definition list items were pairs consisting of a term
and a definition. Now they are pairs consisting of a term and a list of
definitions (each of which can have multiple blocks).

So, the Block type has changed: instead of

DefinitionList [([Inline],[Block])]

we now have

DefinitionList [([Inline],[[Block]])]

Where previously you had to begin each block of a definition with a ':'
on the left margin, now you just indent multiple blocks, just as when
you have multiple blocks in an ordered list item. The ':' now signals
the beginning of a new definition, not a continuation block within
the same definition.

What this means is that definition lists may be interpreted somewhat
differently in 1.3. Example:

apple
: fruit

: computer

would previously have given you a term with a single two-block definition,

<dt>apple</dt>
<dd>
<p>fruit</p>
<p>computer</p>
</dd>

it will now give you a term with two one-block definitions:

<dt>apple</dt>
<dd><p>fruit</p></dd>
<dd><p>computer</p></dd>

I regret the slight break in backwards compatibility, but it seemed
acceptable, since it won't lead to a major difference in how the documents
look on screen or in print output formats. (In most output formats,
there will be no difference in how these are treated; in HTML they are
treated differently, but the difference won't be very apparent on screen
unless you're doing something special with CSS.)

Some other improvements to definition lists:

The marker ':' no longer needs to be flush with the left
margin, so you can do this:

apple
: fruit

You can use '~' as well as ':' (a suggestion of David Wheeler):

apple
~ fruit

You can leave a blank line after the term:

apple

~ fruit

second paragraph of definition

~ computer (second definition for same term)

John