<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
    <title></title>
  </head>
  <body bgcolor="#ffffff" text="#000000">
    On 06/26/2011 02:36 PM, <a class="moz-txt-link-abbreviated" href="mailto:Bowerbird@aol.com">Bowerbird@aol.com</a> wrote:
    <blockquote cite="mid:10bae9.7d728d96.3b38d624@aol.com" type="cite"><font
        face="arial,helvetica"><font color="#000000" face="Verdana"
          lang="0" size="4"><br>
          &gt;&nbsp;&nbsp; If we were only worried about markup we'd <br>
          &gt;&nbsp;&nbsp; just use html, or maybe restructured text, or<br>
          <br>
          but if you were unconcerned about markup,<br>
          you'd just use plain-text, without markdown.<br>
        </font></font></blockquote>
    I didn't say unconcerned - markup conveys meaning as much as the
    words but needs to be secondary to readability if reading the source
    text is important. If reading the source isn't important then it
    doesn't matter if the markup gets in the way.<br>
    <blockquote cite="mid:10bae9.7d728d96.3b38d624@aol.com" type="cite"><font
        face="arial,helvetica"><font color="#000000" face="Verdana"
          lang="0" size="4">
          <br>
          <br>
          &gt;&nbsp;&nbsp; Which is one of the goals of zml but not markdown.<br>
          <br>
          ok...&nbsp; then again, i was _talking_ about z.m.l.,<br>
          and the general issue of auto-assigning an i.d.,<br>
          as well as markdown-extra and multimarkdown,<br>
          and pandoc too, in terms of that general issue,<br>
          one that's ignored completely in gruber's version.<br>
          all in all, i think it was an encompassing overview,<br>
          one doing justice to the issue and its complications.<br>
          <br>
          different use-cases are gonna have differing values,<br>
          but that's a good thing because it broadens our view.<br>
          <br>
          <br>
          &gt;&nbsp;&nbsp; I don't really see an advantage to unique headers<br>
          <br>
          did you look at the examples i gave, from the manual<br>
          for multimarkdown?&nbsp; i think the case is fairly obvious.<br>
          <br>
          i think for any specific instances you examine, you'll<br>
          find it often helps to go unique, rarely (if ever) hurts.<br>
          <br>
          i'd say i see non-advantages to non-unique headers...<br>
        </font></font></blockquote>
    Maybe my needs are too simple. <br>
    <blockquote cite="mid:10bae9.7d728d96.3b38d624@aol.com" type="cite"><font
        face="arial,helvetica"><font color="#000000" face="Verdana"
          lang="0" size="4">
          <br>
          <br>
          &gt;&nbsp;&nbsp; That's something that can be handled <br>
          &gt;&nbsp;&nbsp; as a post-process<br>
          <br>
          in my workflow, there is no "post-process".&nbsp; and still,<br>
          why put off until post-process what you can do now?<br>
        </font></font></blockquote>
    Why think about it so much if a post-process can do it for you? And
    generally, where markdown is used a post-process is available.
    Anyway, we seem to have gotten off-topic here which was, I believe,
    concerning which "markdown extension version" you shoud be
    concentrating on for a conversion process from z.m.l. And i think
    that depends entirely on your intentions forthe converted text. If
    you are seeking general markdown-compatibility you need to stick to
    the base Gruber perl version, which is in general followed by all
    the offshoots. If you are aiming at a specific offshoot then there's
    your answer (pandoc, multimarkdown, what have you).<br>
    <blockquote cite="mid:10bae9.7d728d96.3b38d624@aol.com" type="cite"><font
        face="arial,helvetica"><font color="#000000" face="Verdana"
          lang="0" size="4">
          <br>
          <br>
          &gt;&nbsp;&nbsp; I got distracted with all the multiple blank lines<br>
          <br>
          whoa!&nbsp; seumus!&nbsp; you "got distracted" by blank lines?<br>
          that's getting tripped by the absence of your shadow!<br>
          you are obviously more zen than i am...&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; :+)<br>
        </font></font></blockquote>
    What is the sound of one bracket clapping?<br>
    <blockquote cite="mid:10bae9.7d728d96.3b38d624@aol.com" type="cite"><font
        face="arial,helvetica"><font color="#000000" face="Verdana"
          lang="0" size="4">
          <br>
          <br>
          &gt;&nbsp;&nbsp; I agree that too much markup gums up the editing<br>
          &gt;&nbsp;&nbsp; - and especially the composing. Less is more.<br>
          <br>
          right.&nbsp; writing and rewriting.&nbsp; that's what "editing" is, to
          me...<br>
          everything that happens from blank page to polished product.<br>
          <br>
          and angle-brackets are a terrible distraction.<br>
          <br>
          <br>
          &gt;&nbsp;&nbsp; In general light markup is "cool" because it allows <br>
          &gt;&nbsp;&nbsp; "cool" writing and editing without using html for those
          <br>
          &gt;&nbsp;&nbsp; who can't be bothered.<br>
          <br>
          this is where we agree, yes.<br>
          <br>
          .html is tedium that can be auto-applied after the editing.<br>
          (or any midpoint within the process of doing the editing.)<br>
          <br>
          <br>
          &gt;&nbsp;&nbsp; It's not why I use markdown and <br>
          &gt;&nbsp;&nbsp; I don't really care if it's cool or not. <br>
          &gt;&nbsp;&nbsp; I don't have a blog that I use a light markup for. <br>
          &gt;&nbsp;&nbsp; I don't have a public website that I keep updated <br>
          &gt;&nbsp;&nbsp; using a light markup for content. I just <br>
          &gt;&nbsp;&nbsp; organize my own personal offline information using it.
          <br>
          <br>
          interesting.&nbsp; i don't think that you are the typical use-case,<br>
          but i would love to hear exactly how your system works and<br>
          how markdown adds value to what sounds like a text-base.<br>
        </font></font></blockquote>
    Well, I use headers a lot to separate sections of data. Usually just<br>
    <br>
    Header1<br>
    =======<br>
    <br>
    and <br>
    <br>
    Header2<br>
    -------<br>
    <br>
    which allows me to easily locate the sections in the text. The other
    styles of header do not stand out so much as these and I tend to
    avoid.<br>
    <br>
    I also use lists a lot for outlining, sometimes up to 3 or 4 deep.
    Mostly unordered but occasionally ordered if making note of a
    process for my reference and listing the steps to take. I also
    usually ensure that they all line up neatly to distinguish the
    levels clearly (kinda ocd maybe).<br>
    <br>
    I add links (which are, naturally, only useful in the rendered
    version) to create a hyperlinked mess out of it all, kinda like a
    mind map.<br>
    <br>
    If I know what I'm looking for I just open the source from a file
    browser (like looking up a favourite recipe or recalling a computer
    admin task process steps), if not I boot up the web browser and
    peruse the rendered version following the links to find what I want.<br>
    <br>
    I also cut and paste a lot, for which markdown is passable - there
    is always some cleanup required if it's to be rendered ok. Lists
    copy fine, songs and poetry not so much.<br>
    <br>
    It's a hybrid text-based hyperlinked-based mind dump system. I also
    can add references to online info and images as required (for
    instance sample weld symbols for drawings - I have a lot of
    reference material in this for my job). They of course, like the
    links, work better in the rendered version. It works for me,
    probably not for anyone else. And I have found that for me Markdown
    adds just enough to be useful (except for tables, for which I use
    the python version with tables extension enabled).<br>
    <br>
    As for the distracting blank lines in zml, I just found that when
    reading your source I kept expecting something to fill in the gaps.
    Not a big deal, and if I used it all the time I would probably
    adapt. But that was the first impression from first viewing.
    However, from the application I don't think zml is expected to be
    regularly read from the source file unless you are writing/editing
    it, correct?<br>
    <br>
  </body>
</html>