Universal syntax for Markdown

[Bowerbird at aol.com]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://six.pairlist.net/pipermail/markdown-discuss/attachments/20110817/473c5a2c/attachment.html>