markdown conversions

[Seumas Mac Uilleachan]

On 06/23/2011 05:29 PM, Bowerbird at aol.com wrote:

> alan said:

> >   I think I am in agreement,

> >   if by "isn't necessary" you mean to say that

> >   simply providing more features to Markdown

> >   doesn't force end users to use them,

> >   or even really know they exist.

>

> except that wasn't what i meant.

>

> i mean that it's not necessary to trade simplicity

> in order to get the power of additional features...

>

> indeed, i believe that -- in the purview of a system

> whose chief asset is its simplicity -- that would be

> a bad trade.  and, as i've read gruber, so would he;

> he is an admirer of the grace apple brings to bear.

>

>

> >   I know I am firmly on the side of "this stuff --

> >   footnotes, DLLs, fenced code, attributes on headers,

> >   automatic TOC -- is useful, and sensibly implemented

> >   in the Markdown plain-text spirit, and thus good," myself.

>

> i am all in favor of all of those more-powerful features.

>

> i just don't believe it's necessary to give up _simplicity_

> in order to get them.  you might have to sacrifice some

> _customizability_, but that's an acceptable trade, for me.

>

> at one point, i was ready to discuss a range of stuff that

> could reduce the complexity of markdown variants, but

> nobody else seemed interested in having that discussion.

> so the moment passed.  and i'm not inclined to do it now.

>

> but, just as one for-instance, "markdown extra" lets you

> assign an i.d. attribute to a header, by adding it like this:

> >   ## Header 2 ##            {#header2}

>

> the extra power that this gives users is undeniable, and

> much-needed.  but that convention is just an ugly hack.

> it's extra work, and it's error-prone, plus it looks awful.

> why wouldn't/shouldn't an i.d. be assigned automatically?

>

> so other variants, such as "multimarkdown", do just that.

> but, even in its own user-manual, it gets itself confused,

> with multiple headers being auto-assigned the same i.d.:

>

> >   id="advanced"

> >   id="basic"

> >   id="bibtex"

> >   id="compiling"

> >   id="footnotes"

> >   id="images"

> >   id="rawhtml"

>

> pandoc checks for such duplicates, and appends a suffix

> (-1, -2, etc.) to assure that each one has a unique value...

> that's an ok solution, except that it makes it difficult to

> know what the i.d. is for any specific header because you

> have no idea whether it required an appendage, or not...

>

> i myself, with z.m.l., simply require that each header be

> unique to begin with, thus avoiding that potential glitch.

> and i assign an i.d. to each paragraph, because... why not?

>

> that's how you give the user more power _without_ adding

> more complexity.  (or gumming up the file with any crap.)

>

> -bowerbird


Fascinating --- I read this list and I see feature requests and 
discussions going nowhere because nobody gets beyond the fact the bdfl 
of markdown has gone awol. Thus the base markdown is Gruber's perl 
markdown implementation. Anything that others add are "above and beyond" 
the base (even if they fix edge cases). Thus markdown-_extra_ for tables 
and such.

Yet here we are discussing a zen-to-markdown converter and want to know 
which "above and beyond" version it should adhere to. Sorry but, in 
light of the very real inability of anyone else to take over as bdfl and 
point the way, if you want to convert to markdown you currently need to 
use the base perl markdown as the reference. Otherwise you're converting 
to a superset of markdown.

You could create a converter zml-to-pandoc, or zml-to-multimarkdown, but 
they won't be zml-to-markdown. And really, the choice depends on your 
target audience and what they are going to do with it.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://six.pairlist.net/pipermail/markdown-discuss/attachments/20110623/90fe20ab/attachment.htm>