forking Markdown.pl?

[Tomas Doran]

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.

Cheers
Tom

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 ;)