markdown conversions

[Seumas Mac Uilleachan]

On 06/26/2011 02:36 PM, Bowerbird at aol.com 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

Header1
=======

and

Header2
-------

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

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: <http://six.pairlist.net/pipermail/markdown-discuss/attachments/20110626/4c85e4c8/attachment-0001.html>