Possible bug in handling of HTML comments

[Tomas Doran]

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