Tomas Doran bobtfish at
Sun Mar 16 09:30:58 EDT 2008

On 16 Mar 2008, at 02:57, Seumas Mac Uilleachan wrote:

> LOL that was actually funny :) (No the number is still 42)


> Seriously, it is easy to get up in arms when your "creation" ends

> up becoming bastardised, whatever the form that may take (for

> better or for worse). To be honest, I have not really seen for

> myself that MultiMarkdown has a whole lot to offer, but that's

> just my opinion.

Yeah, I do appreciate the horror of 'you baby' being bastardised ;)
The hysterical raisins for why I'm doing what I'm doing (or, more to
the point, why the code is currently laid out as it is) are just that
I got a CPAN maint bit to Text::MultiMarkdown somewhat before the
maint bit to Text::Markdown..

> Of course perl tends to give me a headache so I really can't be

> all that objective (I really tend to understand PHP better).

Hehe - I read both pretty fluently, however I'm much more pro-perl -
but lets not start the 'which language is best' pissing competition,
I'm all for a Markdown 'ecosystem' with a number of different
implementations targeting different languages / spaces.

I totally respect what Michel Fortin has done - maintaining two
parallel copies of Markdown for PHP both with and without extensions,
however I'm not prepared to go that way myself.

> I really like the fundamentals of Markdown, that what you type is

> basically what you will more or less see in a browser viewing the

> text...

Ditto, I feel that it's a very useful tool, and the evidence shows
that there are a number of intersecting sets of people who all want
to use Markdown for various different things with (or without)
various different extensions.

What I want to do is:

1) Un-fuck Markdown on CPAN so that you're actually going to get
something that works, and has a number of publicly contributed bug
fixes and test suite. (Mostly done, except the code reorganisation to
make Text::Markdown not 'Text::MultiMarkdown with features turned off')

2) Re-write the parser in a big way to make it quicker and more
flexible. Mainly for my own interest - the ways that other markdown
implementations work (I'm thinking pandoc, maruku and python-
markdown's awesome extension mechanism) all rock my world pretty
hard, so I want to play in my language of choice.

Once I actually start getting traction on (2) then I'll be pushing
the new versions as 'developer' releases, so that only the brave (or
foolish) and some of my early adoptors pick up the new crazy
version. ;) (_waves at the Catalyst community, who have built their
new wiki on my code, the crazy fools_)

> However, if you (JG) are willing to let this beautiful creation of

> yours stagnate, then you should not take offense when others take

> up the plate (however tarnished) and take a couple baby steps

> forward...

Indeed. I look forward to the community efforts for a better spec /
test suite so that *all of us* can make Markdown implementations that
predictably inter-operate.

As previously noted on list, my original response in the thread which
JG took umbrage to was meant to be controversial to help promote
healthy discussion about where the wider community wants things to
go, and I'm greatly looking forward to seeing Michel's promised first
draught spec.


P.S. Before anyone reminds me, also I promised to help merge/
contribute all the test cases that I've got with/to MDTest - that's
currently on-hold till I've sorted out the Markdown/Multimarkdown
confusion in my code, as that seems to be offending people's
sensibilities ;)

More information about the Markdown-Discuss mailing list