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 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://six.pairlist.net/pipermail/markdown-discuss/attachments/20110623/0962d32a/attachment.html>
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.) > > -bowerbirdFascinating --- 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>
> From: Bowerbird at aol.com> 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.)This seems like a bad idea to me. I think it's assumed in the mission of Markdown that the content comes first and it should never be dictated or impacted by the markup. Requiring unique headers is much more intrusive than somewhat ugly markup. I do agree that the Markdown Extra implementation isn't ideal. The id hints shouldn't be necessary where a unique id can be generated automatically. MultiMarkdown gets this right in my view. Ids are generated automatically. The markup to specify an id is only necessary for disambiguation. Also, the markup used for ids in MMD is a lot less ugly. For example: ### Overview [MultiMarkdownOverview] ## I think Markdown extra makes a common mistake among extensions - it sacrifices readability of the plain text to ensure a unique element and simplify parsing. Regards, Richard
richard said:> This seems like a bad idea to me.it still seems like a great idea to me, richard... ;+) (i'm responding just for the sake of discussion, not because i consider any of this to be "vital". so understand that this is all very lighthearted.)> in the mission of Markdowni was talking about my own system, which doesn't give a stinky fart about "the mission of markdown", thank you. :+)> that the content comes first and > it should never be dictated or > impacted by the markup.except the markup is the whole purpose of markdown. how can the purpose and the mission be inconsistent? (that's a rhetorical question. just for the discussion.)> Requiring unique headers is much more intrusive > than somewhat ugly markup.maybe, but the unique headers allow anyone at all -- even someone looking at a printout -- to know what the unique i.d. for a given header _will_ be... with certainty. i think that's worth it. besides, forcing headers to be unique gives the reader better navigational aid when they're inside the e-book. (and remember that e-books are the focus of my work.) a repeated header just causes confusion about location. it's better to elaborate on the header so it gets specific. so, in the long run, this isn't just about links at all... it's about making a book with a transparent structure.> Markdown extra makes a common mistake among > extensions - it sacrifices readability of the plain text > to ensure a unique element and simplify parsing.it's clear that duplicated text in the file just junks it up. so, in the abstract, i agree... plus z.m.l.'s readability is far better than markdown's. but, again for discussion, i say "readability of the plain text" is highly over-rated. simply because nobody's gonna read the markdown file. the only reason you added the markdown cruft is so that the content can be turned into .html. so read that .html. why should the reader "imagine" big bold headers when s/he can view rendered headers that _are_ big and bold? the reason light-markup is cool is not better readability, but better _edit-ability_. markup of any kind is obtrusive. and intrusive. it's an obstacle, one that gums up editing. put the focus where it belongs -- on editing, not reading. -bowerbird -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://six.pairlist.net/pipermail/markdown-discuss/attachments/20110625/525dee76/attachment.htm>
seumas said:> Same reason I'm respondinggreat! i love lighthearted discussion! :+)> If we were only worried about markup we'd > just use html, or maybe restructured text, orbut if you were unconcerned about markup, you'd just use plain-text, without markdown.> Which is one of the goals of zml but not markdown.ok... then again, i was _talking_ about z.m.l., and the general issue of auto-assigning an i.d., as well as markdown-extra and multimarkdown, and pandoc too, in terms of that general issue, one that's ignored completely in gruber's version. all in all, i think it was an encompassing overview, one doing justice to the issue and its complications. different use-cases are gonna have differing values, but that's a good thing because it broadens our view.> I don't really see an advantage to unique headersdid you look at the examples i gave, from the manual for multimarkdown? i think the case is fairly obvious. i think for any specific instances you examine, you'll find it often helps to go unique, rarely (if ever) hurts. i'd say i see non-advantages to non-unique headers...> That's something that can be handled > as a post-processin my workflow, there is no "post-process". and still, why put off until post-process what you can do now?> I got distracted with all the multiple blank lineswhoa! seumus! you "got distracted" by blank lines? that's getting tripped by the absence of your shadow! you are obviously more zen than i am... :+)> I agree that too much markup gums up the editing > - and especially the composing. Less is more.right. writing and rewriting. that's what "editing" is, to me... everything that happens from blank page to polished product. and angle-brackets are a terrible distraction.> In general light markup is "cool" because it allows > "cool" writing and editing without using html for those > who can't be bothered.this is where we agree, yes. .html is tedium that can be auto-applied after the editing. (or any midpoint within the process of doing the editing.)> It's not why I use markdown and > I don't really care if it's cool or not. > I don't have a blog that I use a light markup for. > I don't have a public website that I keep updated > using a light markup for content. I just > organize my own personal offline information using it.interesting. i don't think that you are the typical use-case, but i would love to hear exactly how your system works and how markdown adds value to what sounds like a text-base. -bowerbird -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://six.pairlist.net/pipermail/markdown-discuss/attachments/20110626/ff848f02/attachment.html>