On Thursday, June 23, 2011 at 6:49 PM, Seumas Mac Uilleachan wrote:
> On 06/23/2011 05:29 PM, bowerb...@aol.com (mailto:bowerb...@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 cont...@alanhogan.com
_______________________________________________ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net http://six.pairlist.net/mailman/listinfo/markdown-discuss
