doesn't that make you wonder?
tao at klerks.biz
Thu Oct 20 14:13:19 EDT 2011
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)
- MMD Composer (new PEG? why? the behaviours are obviously different, but
how is the syntax tree different?)
+++ John MacFarlane [Thursday, October 20, 2011 1:46 PM]
>+++ Fletcher T. Penney [Oct 20 11 13:22 ]:
>> Others may disagree with me, but I see little reason to reinvent the
wheel when there is a really good wheel sitting in front of us that might
just need some tweaking.
> My more recent lpeg-based markdown implementation, lunamark, is better
than peg-markdown in many respects. It passes more of the tests Michel
Fortin made for PHP Markdown. It is also faster, and (I think) the code is
more readable, since lua is a more expressive language than C.
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
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?
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
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.
From: markdown-discuss-bounces at six.pairlist.net
[mailto:markdown-discuss-bounces at six.pairlist.net] On Behalf Of John
Sent: Thursday, October 20, 2011 1:46 PM
To: Discussion related to Markdown.
Subject: Re: doesn't that make you wonder?
+++ Fletcher T. Penney [Oct 20 11 13:22 ]:
> On Oct 20, 2011, at 12:52 PM, Tao Klerks wrote:
> > OK, I interpret this (besides the quite-reasonable "why should I care?"
vibe), combined with previous references to the PEG grammar(s) implicit in
MultiMarkdown and peg-markdown's implementations, as "a formal specification
> True. "A" formal spec exists, but there needs to be agreement when "THE"
formal spec exists.
> I personally believe that peg-markdown is a fantastic start, and could
easily become the standard after being vetted by various developers and
users around the troublesome edge cases that are out there.
> Others may disagree with me, but I see little reason to reinvent the wheel
when there is a really good wheel sitting in front of us that might just
need some tweaking.
My more recent lpeg-based markdown implementation, lunamark, is better than
peg-markdown in many respects. It passes more of the tests Michel Fortin
made for PHP Markdown. It is also faster, and (I think) the code is more
readable, since lua is a more expressive language than C.
Sorry, I haven't kept track of the differences between the grammars of
peg-markdown and lunamark.
As for portability, well, nothing beats ANSI C, but lua comes close.
The lua interpreter is small is itself implemented in ANSI C, as is the lpeg
library. So lunamark could be made to run on anything that could run
> Yes - you have to have a definition of how you output the HTML.
peg-markdown also does this through example, not through a formal
specification. I'm not an expert on formal grammars, but I wonder if there
is a single formal specification that will define the syntax and the output
in a single document? Or will there need to be a different approach? In
either case, this is also where the test suite will come into play.
It's better, in my opinion, to separate the parser and writer, as is done in
peg-markdown. The parser produces an abstract syntax tree (AST), which the
html and latex writers take as input.
The writers are very simple; the difficulties lie with the parsing itself,
and that's where a spec is really needed.
There could be a separate spec for canonical HTML output.
Markdown-Discuss mailing list
Markdown-Discuss at six.pairlist.net
More information about the Markdown-Discuss