Tomas Doran bobtfish at
Sun Mar 16 21:27:57 EDT 2008

On 17 Mar 2008, at 00:37, John Gabriele wrote:

> So, if the problem is confusion (or perceived confusion) over the

> name, perhaps the Perl modules could be something like `Text::MD` and

> `Text::MDX` (or `Text::MD::Extra`). I'm sure others here could come up

> with more creative names.

Yeah, I see what you mean here - however I just took up the reins
from others who had *already created* these modules, and there are
active communities of people using both - so I don't think there's
any value in changing now, as I'd still need to support the
historical names...

I have added an explanatory note to the upcoming version of
Text::Markdown to make it clear that my code is in no way endorsed by
anyone but me. ;)

> Anyhow, I haven't read all the responses to this thread. It's gotten a

> bit long, and really, I'm actually kinda surprised it's generated so

> much heat. I bet that if someone simply grabbed the most recent

> `` and added:


> 1. Tables. Regular, boring, but unmistakable ones like how the emacs


> 2. Definition lists. My favorite syntax is just:



> 3. The handy header id attribute syntax that PHP Markdown Extra


> Those three things I think would pretty much satisfy a large swath of

> currently unsatisfied users.


> Maybe a reason was already discussed why that can't easily be done and

> I missed it.

MultiMarkdown (and by extension, my Text::MultiMarkdown) already
supports most of your tables and header ids requests (both were
pinched from PHP Markdown Extra by Fletcher Penny when he originally
wrote MultiMarkdown). If you don't want to take the other parts of
MultiMarkdown, then you can trivially disable them in

I think that definition lists would be a good feature to have, but
I'm **very much not** going to add them to either Text::Markdown (as
this is meant to be compatible without extra features),
or Text::MultiMarkdown (ditto for MultiMarkdown).

Given the recent efforts for a spec etc, I'm not considering doing
*anything* to add any features until:

1) I've got the code better factored so that mixing additional
features in is much easier, so that you can easily compose a markdown-
like language.
2) I've seen where the community effort to come up with a better
(i.e. more exact to enable interoperability) spec etc gets to..


More information about the Markdown-Discuss mailing list