On 18 Jan 2008, at 23:09, Fletcher T. Penney wrote:
I was hoping for a more elegant solution (such as not encoding them
in the first place), but for now I guess this will do.
Yeah, it's truly hateful.
I modified the encoding regex to not encode them in the first place,
but it was hella slow, and very very hard to read.
IMNSHO the *correct* way to implement Markdown, is very much to build
a parse tree - which I believe is what the python and ruby guys have
done... You'd not have to do this sort of nasty hacking if you did
that approach right, and it should be a shedload quicker than doing a
zlilion md5 sums (not to mention more flexible, etc).
I'm planning to get there, or at least try to once I've finished
consolidating the CPAN implementations:
http://svn.kulp.ch/cpan/text_multimarkdown/trunk/Todo
http://search.cpan.org/~bobtfish/Text-Markdown-1.0.5/lib/Text/
Markdown.pm
http://search.cpan.org/~bobtfish/Text-MultiMarkdown-1.0.7/lib/Text/
MultiMarkdown.pm
I will add this to the next version of MultiMarkdown as well.
I'm actively developing the CPAN modules - how much will it take to
convince you to merge what you're doing with what I'm doing?
My code currently passes all of the MultiMarkdown testsuite that
MultiMarkdown passes, and all of the Markdown testsuite. (Disclaimer
- except the email hashing, I removed the call to srand() that
nobbled the random number generator each time you called markdown,
and haven't done anything smart to make the tests predictable yet).
The stuff in MultiMarkdown to do xsl transforms to produce latex is
really neat, and I really think that it'd be better for everyone if
there could be 'one true version' of Markdown written in perl. Thoughts?
Cheers
Tom
_______________________________________________
Markdown-Discuss mailing list
[email protected]
http://six.pairlist.net/mailman/listinfo/markdown-discuss
