markdown conversions

[Alan Hogan]

On Thursday, June 23, 2011 at 6:49 PM, Seumas Mac Uilleachan wrote:


>  On 06/23/2011 05:29 PM, Bowerbird at aol.com (mailto: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.


Right. You, Seumas, have eloquently underlined the urgency of the situation. This is why I support David Chambers' fledgling efforts to document the Markdown that is emergent and fragmented, on Github, in hopes of working towards greater unity. And it's why, if I find time, I hope to help in this effort, by documenting differences in a central location. I'm building a start-up at the moment, though, so if anyone else is interested in taking this on, then please do so, by all means.

Alan

http://blogic.com
contact at alanhogan.com



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://six.pairlist.net/pipermail/markdown-discuss/attachments/20110623/f7fdac96/attachment.html>