markdown conversions

Seumas Mac Uilleachan seumas at
Sun Jun 26 17:43:34 EDT 2011

On 06/26/2011 02:36 PM, Bowerbird at wrote:


> > If we were only worried about markup we'd

> > just use html, or maybe restructured text, or


> but if you were unconcerned about markup,

> you'd just use plain-text, without markdown.

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.



> > 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 headers


> did 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...

Maybe my needs are too simple.



> > That's something that can be handled

> > as a post-process


> in my workflow, there is no "post-process". and still,

> why put off until post-process what you can do now?

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).



> > I got distracted with all the multiple blank lines


> whoa! 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... :+)

What is the sound of one bracket clapping?



> > 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.

Well, I use headers a lot to separate sections of data. Usually just




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.

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).

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.

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.

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.

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

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?

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the Markdown-Discuss mailing list