Tomas Doran bobtfish at
Fri Feb 29 06:36:00 EST 2008

On 29 Feb 2008, at 01:00, david parsons wrote:

> In article <9F6C6C2C-F48E-4BA2-BB5B-4F790CDE65B9 at>,

> Tomas Doran <markdown-discuss at> wrote:


>> On 27 Feb 2008, at 23:36, Joseph Lorenzo Hall wrote:

>>> Has anyone thought of forking and maintaining (hopefully

>>> with Gruber's blessing) to fix some of the known bugs?


>> I'm actively maintaining the CPAN modules Text::Markdown, and

>> Text::MultiMarkdown, and longer term, I'd like these to become the

>> canonical distribution.


> Personally, I don't think that would be a very good idea. Not

> because there's anything wrong with your implementation, but

> because the current sticks fairly close to the syntax

> document while your modules extend it in a variety of ways.

Text::Markdown *does not* extend the original Markdown syntax *in any

My implementation does fix a number of bugs / edge cases that aren't
covered in John's test suite, but it *does not* add any extra features.

If Text::Markdown behaves in any way that differs from John's, it should be as either the written spec or test cases
aren't clear, and what Text::Markdown is doing should obviously be
'more correct'.

If anyone can point out that I'm wrong on anything (with the test
case you're using), then I will surely fix the bug and add your test
case, as 'original' brand Markdown compliance is an explicit goal of

> The fact that is moving very slowly is a feature

> when it's the reference implementation. It makes it much

> easier for new implementations to follow the spec when there's

> a stationary reference that can be used for auditing.

With all due respect, I think that describing the state of the
reference implementation as a feature (as opposed to a bug) is a
complete crock of shit.

As an example:

- L1I1
- L1I2
1. L2I1
2. L2I2

In this case (as previously discussed on list), will do
*clearly* the wrong thing. Are you saying that this is a deliberate
feature, and not a bug that should be fixed?

Also - which version of do you consider the reference
implementation? The version actually linked from the daringfireball
markdown page? As this isn't the most recent version that's
available / that John produced, and the newer version(s) fix a load
of bugs (all in edge cases - exactly like the ones that I've been

And what version of the test suite is canonical? No version of passes the latest version of the reference test suite,
but my code does - does that mean that my module is the reference
implementation? John? Bueller? Anyone?

I very much appreciate all the *other* implementations of Markdown
(you'll notice that I credit all the ones I've looked at in the docs
of my module), and I've stolen their test suites, but many / most of
them introduce different 'features', which don't conform to
daringfireball brand Markdown.

I'd very much like there to be a community effort to come to a (more
exact) spec (and test cases) for the 'official' Markdown language,
which everyone can then implement to, but this effort would *have* to
consider that people do want to extend Markdown in various different

Doing 'what the community' wants is a much less trivial problem than
knocking off a Markdown implementation that works for you in
$language_of_choice. However I for one think that we (the community)
can (and should) do better than a 'reference' implementation with
known unfixed bugs that was last officially updated over 4 years ago.

Don't get me wrong, I've got massive respect for John for the
original idea and implementation - I'm not smart enough to have
thought of it first, and, at best, I'm doing incremental improvements
on an idea that he had. However conversations on the list such as the
Markdown mime type are pretty pointless IMO unless we can actually
define what Markdown is, without pointing to a spec with lots of
(widely known and discussed) holes, and a shonky perl script that
doesn't work right on recent versions of perl!


More information about the Markdown-Discuss mailing list