doesn't that make you wonder?

[Fletcher T. Penney]

My "official" stance is:

1) I think consolidation is a good idea

2) consolidation is going to take time and effort

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)

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 "ideal" markup than what we've already written

5) Therefore, I think it's going to take some other purpose/benefit/reward to help motivate the group to work on this.


That doesn't mean it's not a worthy goal --- just that it's going to take some dedication.  And as I've stated here before, it's going to take a clear, well-defined "mission statement" to help guide the effort.  Inevitably, some people will fall into the "kitchen sink" camp and will want every conceivable feature.  Others, like myself, will prefer the smallest number of features necessary to accomplish the needs of most (but not all) users.  Without a clear mission statement, resolving these sorts of disputes will be impossible.


Personally, I found John MacFarlane's peg-markdown to be a very compelling program conceptually, and in its implementation.  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...)

Moving MMD from perl to the PEG/C combo took several months of effort, and required some changes to the MMD syntax.  But I feel like in the end I was left with a program that was faster, more accurate, more useful, and more compatible.  Additionally, I was able to take that PEG and with minimal modifications use it as the basis for the highlighter in MMD Composer.  I could never have done that with the perl script.  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).  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.


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).  But he always had well thought out, well articulated, reasons for his approach.  He was very accommodating when I proposed changes, and was quick to fix bugs.  Agreeing to go with his interpretation was rarely a huge sacrifice, and the benefits far outweighed any downside for me.



As a thought experiment, consider this perspective (some of which may be true, some of it isn't true):

* MultiMarkdown suits my purposes quite well - I can create presentations for lectures, formal letters on custom letterhead, I run several web sites with it...  There's very little in the sphere of writing that it can't do for me.

* I now have a GUI editor that "understands" MMD natively.

* 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.  That doesn't mean anyone will do anything about it, but the requests are out there.

* Other developers are asking me about how to incorporate MMD (and some, like Daniel Jalkut, have actively contributed to making that possible!)

* More and more apps *are* supporting MMD natively, in some fashion or another

* 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

* 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

* I'm already busy maintaining MMD, responding to questions/support issues, and now about to start selling a commercial app built around MMD ---  the last thing I need is to give myself more work that might not show me much benefit

* So, in my world, MMD is the #1, #2, and #3 variant.  (Not to say that is true for anyone else, just for me)


So given these statements (again, some I agree with, some not, but I could see other hypothetical developers in this situation citing them) ---  convince me that an effort to "standardize" would be worth my time and effort?  What benefit am I going to see that justifies several more months (years?) redoing my work?




Another part of this thread mentioned that perhaps there was a sweet spot between Markdown and reStructuredText that was ripe for development. That may be true, and if anyone pursues it, I wish them all the best.  But for me, and I suspect others, I don't *want* something much more formal or complicated than MD/MMD.  That's why I like MD.

What I *do* want is a more standardized approach to interpreting the Markdown syntax.  My guess is that most users don't care which interpretation of lists and indenting we use.  Or whether <strong> supersedes <em> or vice-versa.  I think they just want it to work the same way all the time, regardless of which program/application/platform they are using.



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).  Then, if there can be agreement on a mission statement for additional features, the PEG can be extended to add other "second-tier" features (e.g. tables, footnotes, metadata, etc.).  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.




:)




F-


PS>  Just to stir the pot a bit...  ;)  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.  Just never implemented in Perl....  Please include footnotes...)

And then, if he agreed with it, John could sign off on calling it "Markdown 2.0" or whatever.  He (or someone else) could then update the perl script to be compliant, if desired.  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 "Markdown compliant."  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.  But agreement on the core set would be a huge start.



On Oct 20, 2011, at 9:20 AM, Sherwood Botsford wrote:


> E.g.  Suppose that Fletcher is open minded, and eager for consolidation.  Further suppose that MMD is the #4 variant.  He contacts #1,2,3, and 5, and asks if as a group they can agree on a spec.  #2 says, stuffit, but 1,3 and 5 agree.  They get together, and modify the code.  Each introduces a flag, "-new" to the command line (or preferences for apps) to support the new syntax during the transition period.  Later on -new will be the default behaviour, and -traditional is used for the current behaviour.

> 

> 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.


--  
Fletcher T. Penney
fletcher at fletcherpenney.net

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://six.pairlist.net/pipermail/markdown-discuss/attachments/20111020/b9f7ce2d/attachment-0001.htm>
-------------- 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/b9f7ce2d/attachment-0001.bin>