<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"><head><meta http-equiv=Content-Type content="text/html; charset=us-ascii"><meta name=Generator content="Microsoft Word 14 (filtered medium)"><style><!--
/* Font Definitions */
@font-face
        {font-family:Helvetica;
        panose-1:2 11 6 4 2 2 2 2 2 4;}
@font-face
        {font-family:Wingdings;
        panose-1:5 0 0 0 0 0 0 0 0 0;}
@font-face
        {font-family:Wingdings;
        panose-1:5 0 0 0 0 0 0 0 0 0;}
@font-face
        {font-family:Calibri;
        panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
        {font-family:Tahoma;
        panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
        {font-family:Garamond;
        panose-1:2 2 4 4 3 3 1 1 8 3;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
        {margin:0in;
        margin-bottom:.0001pt;
        font-size:12.0pt;
        font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
        {mso-style-priority:99;
        color:blue;
        text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
        {mso-style-priority:99;
        color:purple;
        text-decoration:underline;}
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
        {mso-style-priority:34;
        margin-top:0in;
        margin-right:0in;
        margin-bottom:0in;
        margin-left:.5in;
        margin-bottom:.0001pt;
        font-size:12.0pt;
        font-family:"Times New Roman","serif";}
span.apple-style-span
        {mso-style-name:apple-style-span;}
span.EmailStyle18
        {mso-style-type:personal-reply;
        font-family:"Calibri","sans-serif";
        color:#1F497D;}
.MsoChpDefault
        {mso-style-type:export-only;
        font-size:10.0pt;}
@page WordSection1
        {size:8.5in 11.0in;
        margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
        {page:WordSection1;}
/* List Definitions */
@list l0
        {mso-list-id:1136610249;
        mso-list-type:hybrid;
        mso-list-template-ids:1239595902 67698689 67698691 67698693 67698689 67698691 67698693 67698689 67698691 67698693;}
@list l0:level1
        {mso-level-number-format:bullet;
        mso-level-text:\F0B7;
        mso-level-tab-stop:none;
        mso-level-number-position:left;
        text-indent:-.25in;
        font-family:Symbol;}
@list l0:level2
        {mso-level-number-format:bullet;
        mso-level-text:o;
        mso-level-tab-stop:none;
        mso-level-number-position:left;
        text-indent:-.25in;
        font-family:"Courier New";}
@list l0:level3
        {mso-level-number-format:bullet;
        mso-level-text:\F0A7;
        mso-level-tab-stop:none;
        mso-level-number-position:left;
        text-indent:-.25in;
        font-family:Wingdings;}
@list l0:level4
        {mso-level-number-format:bullet;
        mso-level-text:\F0B7;
        mso-level-tab-stop:none;
        mso-level-number-position:left;
        text-indent:-.25in;
        font-family:Symbol;}
@list l0:level5
        {mso-level-number-format:bullet;
        mso-level-text:o;
        mso-level-tab-stop:none;
        mso-level-number-position:left;
        text-indent:-.25in;
        font-family:"Courier New";}
@list l0:level6
        {mso-level-number-format:bullet;
        mso-level-text:\F0A7;
        mso-level-tab-stop:none;
        mso-level-number-position:left;
        text-indent:-.25in;
        font-family:Wingdings;}
@list l0:level7
        {mso-level-number-format:bullet;
        mso-level-text:\F0B7;
        mso-level-tab-stop:none;
        mso-level-number-position:left;
        text-indent:-.25in;
        font-family:Symbol;}
@list l0:level8
        {mso-level-number-format:bullet;
        mso-level-text:o;
        mso-level-tab-stop:none;
        mso-level-number-position:left;
        text-indent:-.25in;
        font-family:"Courier New";}
@list l0:level9
        {mso-level-number-format:bullet;
        mso-level-text:\F0A7;
        mso-level-tab-stop:none;
        mso-level-number-position:left;
        text-indent:-.25in;
        font-family:Wingdings;}
ol
        {margin-bottom:0in;}
ul
        {margin-bottom:0in;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]--></head><body lang=EN-US link=blue vlink=purple><div class=WordSection1><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>OK, I interpret this (besides the quite-reasonable &quot;why should I care?&quot; vibe), combined with previous references to the PEG grammar(s) implicit in MultiMarkdown and peg-markdown's implementations, as &quot;a formal specification already exists&quot;.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p>&nbsp;</o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>That sounds fine - I'd love to use peg-(multi)markdown in my programs, but I see two practical problems for that right now:<o:p></o:p></span></p><p class=MsoListParagraph style='text-indent:-.25in;mso-list:l0 level1 lfo1'><![if !supportLists]><span style='font-size:11.0pt;font-family:Symbol;color:#1F497D'><span style='mso-list:Ignore'>&middot;<span style='font:7.0pt "Times New Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span></span></span><![endif]><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>A C library, while portable to any processor architecture, if not portable to any development environment, and certainly not future-proof. I, personally, would like to be able to rely on the exact same syntax not only across the OSs that Fletcher mentions, but also in C# code (that can be sandboxed safely - no P/Invoke calls to unsafe code) and also in browsers. There are numerous other environments (Java, etc) where a similar &quot;safe code&quot; requirement precludes the use of a C library (at least in browser and other high-sandboxing environments).<o:p></o:p></span></p><p class=MsoListParagraph style='text-indent:-.25in;mso-list:l0 level1 lfo1'><![if !supportLists]><span style='font-size:11.0pt;font-family:Symbol;color:#1F497D'><span style='mso-list:Ignore'>&middot;<span style='font:7.0pt "Times New Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span></span></span><![endif]><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>The PEG grammars(s) may be formal reproducible reusable specifications, but my understanding is that they are not so meaningful without a definition of what they map to. If my brief reading on this is correct, a PEG grammar allows you to define behaviours to be executed upon encountering certain source structures; those behaviours implement a conversion to HTML, or latex, or whatever, but are implicit in the Program, not the Specification/Grammar<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p>&nbsp;</o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>So if we take the current PEG-based implementations as a starting point, what would it take to produce a specification that formally establishes not only the source structures to be matched, but also the behaviour/conversions to be implemented against them? Is this just a question of detailed documentation and an open test-suite?<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p>&nbsp;</o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Another applicable question is: are PEG grammars easily usable in other environments? A brief search suggests so (js: </span><a href="http://stackoverflow.com/questions/79584/are-there-any-parsing-expression-grammar-peg-libraries-for-javascript-or-php">http://stackoverflow.com/questions/79584/are-there-any-parsing-expression-grammar-peg-libraries-for-javascript-or-php</a>, <span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>C#: </span><a href="http://www.codeproject.com/KB/recipes/grammar_support_1.aspx">http://www.codeproject.com/KB/recipes/grammar_support_1.aspx</a><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'> not GPL-compatible, sadly&#8230;); does anyone know how fesible it is to take the existing PEG grammar(s) and reuse them in other languages?<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p>&nbsp;</o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Thanks,<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Tao<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p>&nbsp;</o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p>&nbsp;</o:p></span></p><div><div style='border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in'><p class=MsoNormal><b><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'>From:</span></b><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'> markdown-discuss-bounces@six.pairlist.net [mailto:markdown-discuss-bounces@six.pairlist.net] <b>On Behalf Of </b>Fletcher T. Penney<br><b>Sent:</b> Thursday, October 20, 2011 12:28 PM<br><b>To:</b> Discussion related to Markdown.<br><b>Subject:</b> Re: doesn't that make you wonder?<o:p></o:p></span></p></div></div><p class=MsoNormal><o:p>&nbsp;</o:p></p><div><p class=MsoNormal>My &quot;official&quot; stance is:<o:p></o:p></p></div><div><p class=MsoNormal><o:p>&nbsp;</o:p></p></div><div><p class=MsoNormal>1) I think consolidation is a good idea<o:p></o:p></p></div><div><p class=MsoNormal><o:p>&nbsp;</o:p></p></div><div><p class=MsoNormal>2) consolidation is going to take time and effort<o:p></o:p></p></div><div><p class=MsoNormal><o:p>&nbsp;</o:p></p></div><div><p class=MsoNormal>3) those of us who have written our own variants are probably happy with how they work (or else we would have changed them already)<o:p></o:p></p></div><div><p class=MsoNormal><o:p>&nbsp;</o:p></p></div><div><p class=MsoNormal>4) These developers, as individuals, might not actually see much benefit from the time and effort it takes to standardize on something that, almost by definition, will be less close to our own &quot;ideal&quot; markup than what we've already written<o:p></o:p></p></div><div><p class=MsoNormal><o:p>&nbsp;</o:p></p></div><div><p class=MsoNormal>5) Therefore, I think it's going to take some other purpose/benefit/reward to help motivate the group to work on this.<o:p></o:p></p></div><div><p class=MsoNormal><o:p>&nbsp;</o:p></p></div><div><p class=MsoNormal><o:p>&nbsp;</o:p></p></div><div><p class=MsoNormal>That doesn't mean it's not a worthy goal --- just that it's going to take some dedication. &nbsp;And as I've stated here before, it's going to take a clear, well-defined &quot;mission statement&quot; to help guide the effort. &nbsp;Inevitably, some people will fall into the &quot;kitchen sink&quot; camp and will want every conceivable feature. &nbsp;Others, like myself, will prefer the smallest number of features necessary to accomplish the needs of most (but not all) users. &nbsp;Without a clear mission statement, resolving these sorts of disputes will be impossible.<o:p></o:p></p></div><div><p class=MsoNormal><o:p>&nbsp;</o:p></p></div><div><p class=MsoNormal><o:p>&nbsp;</o:p></p></div><div><p class=MsoNormal>Personally, I found John MacFarlane's peg-markdown to be a very compelling program conceptually, and in its implementation. &nbsp;The idea of a parsing expression grammar (PEG) that could be reused for other purposes was intriguing (though I had no idea what it was when I read about it...)<o:p></o:p></p></div><div><p class=MsoNormal><o:p>&nbsp;</o:p></p></div><div><p class=MsoNormal>Moving MMD from perl to the PEG/C combo took several months of effort, and required some changes to the MMD syntax. &nbsp;But I feel like in the end I was left with a program that was faster, more accurate, more useful, and more compatible. &nbsp;Additionally, I was able to take that PEG and with minimal modifications use it as the basis for the highlighter in MMD Composer. &nbsp;I could never have done that with the perl script. &nbsp;And with the PEG, I know that both apps will interpret the source in the same manner (aside from any bugs I may have introduced in the migration). &nbsp;And any other developer that wants to implement MMD in another language/environment/OS/whatever, can use that PEG to ensure that their version of the MMD syntax matches mine.<o:p></o:p></p></div><div><p class=MsoNormal><o:p>&nbsp;</o:p></p></div><div><p class=MsoNormal><o:p>&nbsp;</o:p></p></div><div><p class=MsoNormal>I didn't always agree with every decision John made in defining the PEG for peg-markdown (which forms the basis for peg-multimarkdown/MMD 3.0). &nbsp;But he always had well thought out, well articulated, reasons for his approach. &nbsp;He was very accommodating when I proposed changes, and was quick to fix bugs. &nbsp;Agreeing to go with his interpretation was rarely a huge sacrifice, and the benefits far outweighed any downside for me.<o:p></o:p></p></div><div><p class=MsoNormal><o:p>&nbsp;</o:p></p></div><div><p class=MsoNormal><o:p>&nbsp;</o:p></p></div><div><p class=MsoNormal><o:p>&nbsp;</o:p></p></div><div><p class=MsoNormal>As a thought experiment, consider this perspective (some of which may be true, some of it isn't true):<o:p></o:p></p></div><div><p class=MsoNormal><o:p>&nbsp;</o:p></p></div><div><p class=MsoNormal>* MultiMarkdown suits my purposes quite well - I can create presentations for lectures, formal letters on custom letterhead, I run several web sites with it... &nbsp;There's very little in the sphere of writing that it can't do for me.<o:p></o:p></p></div><div><p class=MsoNormal><o:p>&nbsp;</o:p></p></div><div><p class=MsoNormal>* I now have a GUI editor that &quot;understands&quot; MMD natively.<o:p></o:p></p></div><div><p class=MsoNormal><o:p>&nbsp;</o:p></p></div><div><p class=MsoNormal>* There's not a popular text editing tool/app that I'm aware of (for the Mac at least) that does not have requests out there asking for them to support MMD. &nbsp;That doesn't mean anyone will do anything about it, but the requests are out there.<o:p></o:p></p></div><div><p class=MsoNormal><o:p>&nbsp;</o:p></p></div><div><p class=MsoNormal>* Other developers are asking me about how to incorporate MMD (and some, like Daniel Jalkut, have actively contributed to making that possible!)<o:p></o:p></p></div><div><p class=MsoNormal><o:p>&nbsp;</o:p></p></div><div><p class=MsoNormal>* More and more apps *are* supporting MMD natively, in some fashion or another<o:p></o:p></p></div><div><p class=MsoNormal><o:p>&nbsp;</o:p></p></div><div><p class=MsoNormal>* I expect those numbers to grow now that MMD is a C program/library, and when I clean it up enough to be easier for developers to use, I suspect it will grow even faster<o:p></o:p></p></div><div><p class=MsoNormal><o:p>&nbsp;</o:p></p></div><div><p class=MsoNormal>* I can change MMD any time I get a new itch that it doesn't already scratch --- I don't have to wait on anyone, or worse, a committee of anyones<o:p></o:p></p></div><div><p class=MsoNormal><o:p>&nbsp;</o:p></p></div><div><p class=MsoNormal>* I'm already busy maintaining MMD, responding to questions/support issues, and now about to start selling a commercial app built around MMD --- &nbsp;the last thing I need is to give myself more work that might not show me much benefit<o:p></o:p></p></div><div><p class=MsoNormal><o:p>&nbsp;</o:p></p></div><div><p class=MsoNormal>* So, in my world, MMD is the #1, #2, and #3 variant. &nbsp;(Not to say that is true for anyone else, just for me)<o:p></o:p></p></div><div><p class=MsoNormal><o:p>&nbsp;</o:p></p></div><div><p class=MsoNormal><o:p>&nbsp;</o:p></p></div><div><p class=MsoNormal>So given these statements (again, some I agree with, some not, but I could see other hypothetical developers in this situation citing them) --- &nbsp;convince me that an effort to &quot;standardize&quot; would be worth my time and effort? &nbsp;What benefit am I going to see that justifies several more months (years?) redoing my work?<o:p></o:p></p></div><div><p class=MsoNormal><o:p>&nbsp;</o:p></p></div><div><p class=MsoNormal><o:p>&nbsp;</o:p></p></div><div><p class=MsoNormal><o:p>&nbsp;</o:p></p></div><div><p class=MsoNormal><o:p>&nbsp;</o:p></p></div><div><p class=MsoNormal>Another part of this thread mentioned that perhaps there was a sweet spot between&nbsp;Markdown and reStructuredText that was ripe for development. That may be true, and if anyone pursues it, I wish them all the best. &nbsp;But for me, and I suspect others, I don't *want* something much more formal or complicated than MD/MMD. &nbsp;That's why I like MD.<o:p></o:p></p></div><div><p class=MsoNormal><o:p>&nbsp;</o:p></p></div><div><p class=MsoNormal>What I *do* want is a more standardized approach to interpreting the Markdown syntax. &nbsp;My guess is that most users don't care which interpretation of lists and indenting we use. &nbsp;Or whether &lt;strong&gt; supersedes &lt;em&gt; or vice-versa. &nbsp;I think they just want it to work the same way all the time, regardless of which program/application/platform they are using.<o:p></o:p></p></div><div><p class=MsoNormal><o:p>&nbsp;</o:p></p></div><div><p class=MsoNormal><o:p>&nbsp;</o:p></p></div><div><p class=MsoNormal><o:p>&nbsp;</o:p></p></div><div><p class=MsoNormal>From that perspective, I'm fine with agreeing that the PEG from peg-markdown becomes the canon for the core Markdown syntax in whatever new language we create (subject to a round of debate/discussion on some of the edge cases). &nbsp;Then, if there can be agreement on a mission statement for additional features, the PEG can be extended to add other &quot;second-tier&quot; features (e.g. tables, footnotes, metadata, etc.). &nbsp;I believe that this second part is going to be the more difficult and time consuming part, so why waste time on the first part when it could be relatively easy.<o:p></o:p></p></div><div><p class=MsoNormal><o:p>&nbsp;</o:p></p></div><div><p class=MsoNormal><o:p>&nbsp;</o:p></p></div><div><p class=MsoNormal><o:p>&nbsp;</o:p></p></div><div><p class=MsoNormal>:)<o:p></o:p></p></div><div><p class=MsoNormal><o:p>&nbsp;</o:p></p></div><div><p class=MsoNormal><o:p>&nbsp;</o:p></p></div><div><p class=MsoNormal><o:p>&nbsp;</o:p></p></div><div><p class=MsoNormal>F-<o:p></o:p></p></div><div><p class=MsoNormal><o:p>&nbsp;</o:p></p></div><div><p class=MsoNormal><o:p>&nbsp;</o:p></p></div><div><p class=MsoNormal>PS&gt; &nbsp;Just to stir the pot a bit... &nbsp;;) &nbsp;Since it seems clear that John Gruber is no longer developing his own version of Markdown, it would be nice if he would review whatever standard arises for the core feature set (not any new features, just the original set - except footnotes - for goodness sakes he all but wrote the footnote syntax himself and even used it on his own site. &nbsp;Just never implemented in Perl.... &nbsp;Please include footnotes...)<o:p></o:p></p></div><div><p class=MsoNormal><o:p>&nbsp;</o:p></p></div><div><p class=MsoNormal>And then, if he agreed with it, John could sign off on calling it &quot;Markdown 2.0&quot; or whatever. &nbsp;He (or someone else) could then update the perl script to be compliant, if desired. &nbsp;But at least there could be a well-defined Markdown syntax that everyone could refer to as canon. It could form the basis for a test suite that other others could use to claim their software was &quot;Markdown compliant.&quot; &nbsp;It would then be up to various developers to agree on a canon for alternate features (tables, metadata, etc) and this would still need a different name. &nbsp;But agreement on the core set would be a huge start.<o:p></o:p></p></div><div><p class=MsoNormal><o:p>&nbsp;</o:p></p></div><div><p class=MsoNormal><o:p>&nbsp;</o:p></p></div><p class=MsoNormal><o:p>&nbsp;</o:p></p><div><div><p class=MsoNormal>On Oct 20, 2011, at 9:20 AM, Sherwood Botsford wrote:<o:p></o:p></p></div><p class=MsoNormal><br><br><o:p></o:p></p><p class=MsoNormal><span class=apple-style-span><span style='font-size:18.0pt;font-family:"Garamond","serif";color:#006600'>E.g.&nbsp; Suppose that Fletcher is open minded, and eager for consolidation.&nbsp; Further suppose that MMD is the #4 variant.&nbsp; He contacts #1,2,3, and 5, and asks if as a group they can agree on a spec.&nbsp; #2 says, stuffit, but 1,3 and 5 agree.&nbsp; They get together, and modify the code.&nbsp; Each introduces a flag, &quot;-new&quot; to the command line (or preferences for apps) to support the new syntax during the transition period.&nbsp; Later on -new will be the default behaviour, and -traditional is used for the current behaviour.</span></span><span style='font-size:18.0pt;font-family:"Garamond","serif";color:#006600'><br><br><span class=apple-style-span>If agreement is reached, then the group looks at variants 6,7,8,9 and inquires if they would like to join in this effort.</span><br><br></span><o:p></o:p></p></div><p class=MsoNormal><o:p>&nbsp;</o:p></p><div><div><div><div><div><div><div><div><p class=MsoNormal><span style='font-size:13.5pt;font-family:"Helvetica","sans-serif";color:black'>-- &nbsp;<o:p></o:p></span></p></div><div><p class=MsoNormal><span style='font-size:13.5pt;font-family:"Helvetica","sans-serif";color:black'>Fletcher T. Penney<o:p></o:p></span></p></div><div><p class=MsoNormal><span style='font-size:13.5pt;font-family:"Helvetica","sans-serif";color:black'><a href="mailto:fletcher@fletcherpenney.net">fletcher@fletcherpenney.net</a><o:p></o:p></span></p></div></div></div></div></div></div></div></div><p class=MsoNormal><o:p>&nbsp;</o:p></p></div></body></html>