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
`Markdown.pl` and added:

1. Tables. Regular, boring, but unmistakable ones like how the emacs
<snip>
2. Definition lists. My favorite syntax is just:
<snip>

3. The handy header id attribute syntax that PHP Markdown Extra
<snip>
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 Text::MultiMarkdown.

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 Markdown.pl 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..

Cheers
Tom

_______________________________________________
Markdown-Discuss mailing list
[email protected]
http://six.pairlist.net/mailman/listinfo/markdown-discuss

Reply via email to