doesn't that make you wonder?

[Fletcher T. Penney]

On Oct 20, 2011, at 2:13 PM, Tao Klerks wrote:


> OK, so pardon my ignorance here: Am I right in assuming that there are are

> two people here who are responsible for at least 5 different but

> to-varying-degrees-compatible markdown systems/dialects?

> 

> Fletcher T. Penney:

> - MultiMarkdown (original version/codebase)

> - peg-MultiMarkdown

> - MMD Composer (new PEG? why? the behaviours are obviously different, but

> how is the syntax tree different?)


peg-mmd (MMD 3) replaces the old perl version 2.  v 2 still exists on github, but I am no longer actively developing it.  Trying to bring it into compliance with MMD 3 was going to take too much work to be justified.  Anyone else is welcome to continue working on it, however.

Composer uses the same syntax as MMD 3, and uses MMD 3 itself to handle previews/exports. The PEG has to be modified because we are highlighting, not parsing.  PEGs are not drop-in magic bundles that do everything for you. They define how to parse the input text.  It's up to the programmer to do something useful with that parsing.  But think of Composer as an implementation of MMD 3, not as something distinct in this sense.



> John MacFarlane

> - peg-markdown

> - pandoc 

> - Lunamark



<snip>


> But the main problem here, you both seem to agree, is to define a formal

> grammar that will define the correct AST for a base/common Markdown syntax,

> and could have a series of tests (be those the original John Gruber tests,

> or Michel Fortin's later ones) define "compliance" for a base set of

> features?


Yes.  I think it's useful to have a "reference" implementation that demonstrates that formal grammar.  But the standard should be the grammar itself, not a specific implementation (which was one of the problems with Gruber's "the implementation is the reference" approach).


> John, you say the lunamark implementation is better, passes more of Michel

> Fortin's tests, and is "different" to peg-markdown to an unknown degree

> (because it presumably uses a different syntax to express the same grammar

> concepts?)... Is there any way for you and Fletcher to (without any

> significant amount of conversion work) understand what, if anything, would

> need to change in peg-markdown for it to represent an accurate common ground

> between both peg-MultiMarkdown and LunaMark?


If John brought peg-markdown into compliance with lunamark, then by extension peg-multimarkdown would be compliant when I pulled his changes.


> Fletcher, there's one thing I'm not completely clear on: besides the syntax

> extensions that you made, is peg-MultiMarkdown still basically doing the

> same as peg-markdown for 99% of cases where peg-MultiMarkdown's

> features/extensions are not explicitly/purposefully used by an end-user? Or

> have you made changes to the "base" workings to accommodate your additional

> syntax requirements?


If you run peg-multimarkdown with the "compliant" flag, it *should* be 100% identical in output to peg-markdown.  Composer has a preference that does just that.  Any differences between the two are unintentional, and problems could be readily fixed when identified.


> Sorry if I'm being overly familiar here - I just felt, for a few moments,

> like I was seeing some light at the end of the tunnel.


That's why I brought up some of the points the way I did today.  I feel like MacFarlane has a done a great job formalizing much of the Markdown syntax.  That's not to say that his interpretation is entirely correct, or that others have not done an equally good job.  When I decided to rewrite MMD last fall, his implementation seemed to be the most flexible, cross-platform, and easily understood approach.  So I went with it, and now it's the one I'm most familiar with.

That's why I feel like it is 90% of the way towards being a useable standard.  Other developers can test out various edge cases and bring them up for discussion.  Appropriate changes can be made as needed to the underlying formal grammar.  A test suite can then be developed.

I believe that the issue of standardizing the syntax extensions will be a more challenging problem to tackle.  But this would be a huge step, and probably generate momentum that would carry over.


F-

--  
Fletcher T. Penney
fletcher at fletcherpenney.net

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://six.pairlist.net/pipermail/markdown-discuss/attachments/20111020/8f25e1a0/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4899 bytes
Desc: not available
Url : <http://six.pairlist.net/pipermail/markdown-discuss/attachments/20111020/8f25e1a0/attachment-0001.bin>