Universal syntax for Markdown

[Fletcher T. Penney]

Just to clarify my thoughts about some of bowerbird's comments (which are his, and do not represent my own opinions):

1) I don't think that the MMD feature set and/or implementation is necessarily the best for everyone - just because I like it, doesn't make it right for all uses.  That said, there are many who do find it useful.

2) I have no desire to have MMD take over the name "markdown" - that belongs to Gruber and his work.  I *do* think it would be useful if some as yet unwritten consensus standard could become "Markdown 2.0" - that *would* require Gruber's approval.  It may or may not contain features outside of the current base, but could at least become the canonical way to handle current edge cases.

3) Terpstra and Jalkut have made use of MMD in various ways and made it better by their work and contributions, and MacFarlane has certainly helped me by his own creation of peg-markdown. I'm not sure that I would speak for them to the point of saying they have vetted it, however.  To my knowledge, MacFarlane has no plans to stop developing peg-markdown (even if just for bug fixes) or pandoc (which has features and output formats that MMD does not).  To be clear, I am not stating that any of these other developers feel MMD is the current "implementation to beat." (They may feel that way, but I am not aware that they have said so publicly.)

4) I'm sure some people think that I am dogmatic, but I try not to be.  ;)


F-



On Aug 17, 2011, at 6:54 PM, Bowerbird at aol.com wrote:


> here are some of the things that i think.

> i would expect some people to disagree.

> 

> ***

> 

> it's great to see this discussion taking off...

> 

> and great to see penney and macfarlane here,

> taking part...

> 

> ***

> 

> the combination of multimarkdown with pandoc

> -- especially given penney's recent advances --

> can't be defeated by another markdown superset.

> 

> so the stalemate has now been effectively resolved.

> 

> you either achieve parity with multimarkdown, or fold.

> 

> and a number of developers will decide that there is

> no future in "achieving parity" with the front-runner.

> 

> nonetheless, the deadlock is broken, the standoff over.

> 

> ***

> 

> it will be interesting to see if gruber lets you use the name

> "markdown", or if he has some vested interest in keeping it.

> 

> ***

> 

> penney cites gruber:

> >   The overriding design goal for Markdown’s

> >   formatting syntax is to make it as readable as possible. 

> >   The idea is that a Markdown-formatted document should 

> >   be publishable as-is, as plain text, without looking like 

> >   it’s been marked up with tags or formatting instructions.

> 

> um, whenever i look at a multimarkdown input-file, it certainly

> does _not_ look like it's "as readable as possible" to my eyes.

> 

> i see all kinds of crap that won't appear on the printed page

> (or the .html screen), and all that crap is a major distraction.

> 

> so i think a lot of you guys are fooling yourselves that your

> markdown input-files are "readable" and even "publishable", 

> and i don't believe the general public is gonna buy that line.

> because they want something that really _is_ readable as-is.

> (because you need to read a document as you're editing it.)

> 

> now i am obviously being swayed by the fact that i invented

> a light-markup format which specifically eschews such crap,

> and does it successfully, so i know that it is entirely possible.

> 

> and perhaps i'm overestimating the importance of that benefit

> to the general public and its uptake of a light-markup format.

> 

> we'll see...

> 

> but i suggest that it might be good for you to make some use

> of this opportunity which "unification" presents, enabling you

> to go back to the drawing-board and strip away what you can.

> 

> ***

> 

> making a new start will also allow you to rethink the process.

> 

> my recommendation would be that you return to the basics,

> in the sense that you explain the conversion in pseudo-code.

> 

> here is the pseudo-code for my conversion process:

> 1.  split the document into "chunks", separated by blank lines.

> 2.  walk through your array of chunks, assigning each its tag.

> 3.  output chunks based on tag (plus maybe neighbors' tags).

> 

> as you can see, this process works in any language/compiler.

> 

> and it's so simple that even a beginner-programmer can write

> and/or maintain such a converter routine.  these concerns are

> vital, especially if you lose developers -- as i predicted above.

> 

> but they are also important from a _pedagogical_ standpoint,

> in the sense that you need to educate users about the format.

> there should never be any doubt what a specific chunk will be.

> crystal clarity in the end-user's mind should be your objective.

> 

> ***

> 

> there is no need for an influx of cash to create a solution.

> 

> which is good, because there is no influx of cash coming.

> 

> but even if there _was_, the markdown community would

> _not_ know how to allocate that cash to obtain a solution.

> indeed, there is serious doubt that it could even be done...

> it would likely cause little but dissension and hard feelings.

> 

> ***

> 

> there's no need for a resolution to take "18 to 36 months"...

> it could be done in 18-36 days, or maybe even 18-36 hours.

> (how long does it take to say "standardize on multimarkdown".)

> 

> macfarlane has vetted multimarkdown very carefully, so if he

> can't tell us anything "wrong" with it, there's nothing "wrong".

> (ditto on terpstra and jalkut, who decided on multimarkdown.)

> 

> so if you've got beef, you'll have to thrash it out with fletcher.

> (and if you feel you'll beat the multimarkdown/pandoc combo,

> especially with penney's "composer" debut, you are deluded.)

> 

> on the bright side, penney doesn't seem to be too dogmatic,

> so if you have a good argument for change, he'll likely listen.

> 

> ***

> 

> speaking of the markdown community, it might be good if you

> actually started enabling such an entity, so that you could listen

> to what it has to say...  a lot of you do speculation about "what"

> your user-base "wants", but you're more-or-less just guessing.

> if you had a way to poll the community, the answers you'd get

> would be _much_ more reliable, and accurate, and actionable...

> 

> ***

> 

> and of course it'd be good even if you just got the _developers_

> on-board and talking to each other.  for instance, in recent days,

> brett terpstra and daniel "punkass" jalkut have made big advances

> in markdown that have moved it forward in a significant way, yet

> neither of them is here on this list, or talking to the "community".

> 

> ***

> 

> one of the things that might come out of such widespread input

> is a strong consensus on what's "really needed" and what's not...

> 

> my work has always been defined by _books_, so if a certain

> structure was one that was found (even if rarely) in _books_,

> then it was a structure which i needed to be able to support.

> you don't seem to have such a laser-focus; it might help you.

> 

> ***

> 

> meta-data belongs at the end of a document, not the start of it.

> 

> ***

> 

> anyway, those are some of the things that came up while i was

> chatting with grandmother at our bridge club the other night...

> 

> -bowerbird

> _______________________________________________

> Markdown-Discuss mailing list

> Markdown-Discuss at six.pairlist.net

> http://six.pairlist.net/mailman/listinfo/markdown-discuss


--  
Fletcher T. Penney
fletcher at fletcherpenney.net




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://six.pairlist.net/pipermail/markdown-discuss/attachments/20110817/adaa297b/attachment-0001.htm>