forking Markdown.pl?

[Tomas Doran]

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