forking Markdown.pl?

[Tomas Doran]

On 29 Feb 2008, at 01:00, david parsons wrote:


> In article <9F6C6C2C-F48E-4BA2-BB5B-4F790CDE65B9 at bobtfish.net>,

> Tomas Doran  <markdown-discuss at six.pairlist.net> wrote:

>>

>> On 27 Feb 2008, at 23:36, Joseph Lorenzo Hall wrote:

>>> Has anyone thought of forking and maintaining Markdown.pl (hopefully

>>> with Gruber's blessing) to fix some of the known bugs?

>>

>> I'm actively maintaining the CPAN modules Text::Markdown, and

>> Text::MultiMarkdown, and longer term, I'd like these to become the

>> canonical distribution.

>

>      Personally, I don't think that would be a very good idea.  Not

>      because there's anything wrong with your implementation, but

>      because the current Markdown.pl sticks fairly close to the syntax

>      document while your modules extend it in a variety of ways.


Text::Markdown *does not* extend the original Markdown syntax *in any  
way*.

My implementation does fix a number of bugs / edge cases that aren't  
covered in John's test suite, but it *does not* add any extra features.

If Text::Markdown behaves in any way that differs from John's  
Markdown.pl, it should be as either the written spec or test cases  
aren't clear, and what Text::Markdown is doing should obviously be  
'more correct'.

If anyone can point out that I'm wrong on anything (with the test  
case you're using), then I will surely fix the bug and add your test  
case, as 'original' brand Markdown compliance is an explicit goal of  
Text::Markdown.


>      The fact that Markdown.pl is moving very slowly is a feature

>      when it's the reference implementation.   It makes it much

>      easier for new implementations to follow the spec when there's

>      a stationary reference that can be used for auditing.


With all due respect, I think that describing the state of the  
reference implementation as a feature (as opposed to a bug) is a  
complete crock of shit.

As an example:

- L1I1
- L1I2
1. L2I1
2. L2I2

In this case (as previously discussed on list), Markdown.pl will do  
*clearly* the wrong thing. Are you saying that this is a deliberate  
feature, and not a bug that should be fixed?

Also - which version of Markdown.pl do you consider the reference  
implementation? The version actually linked from the daringfireball  
markdown page? As this isn't the most recent version that's  
available / that John produced, and the newer version(s) fix a load  
of bugs (all in edge cases - exactly like the ones that I've been  
fixing).

And what version of the test suite is canonical? No version of  
Markdown.pl passes the latest version of the reference test suite,  
but my code does - does that mean that my module is the reference  
implementation? John? Bueller? Anyone?


I very much appreciate all the *other* implementations of Markdown  
(you'll notice that I credit all the ones I've looked at in the docs  
of my module), and I've stolen their test suites, but many / most of  
them introduce different 'features', which don't conform to  
daringfireball brand Markdown.

I'd very much like there to be a community effort to come to a (more  
exact) spec (and test cases) for the 'official' Markdown language,  
which everyone can then implement to, but this effort would *have* to  
consider that people do want to extend Markdown in various different  
ways...


Doing 'what the community' wants is a much less trivial problem than  
knocking off a Markdown implementation that works for you in  
$language_of_choice. However I for one think that we (the community)  
can (and should) do better than a 'reference' implementation with  
known unfixed bugs that was last officially updated over 4 years ago.

Don't get me wrong, I've got massive respect for John for the  
original idea and implementation - I'm not smart enough to have  
thought of it first, and, at best, I'm doing incremental improvements  
on an idea that he had. However conversations on the list such as the  
Markdown mime type are pretty pointless IMO unless we can actually  
define what Markdown is, without pointing to a spec with lots of  
(widely known and discussed) holes, and a shonky perl script that  
doesn't work right on recent versions of perl!

Cheers
Tom