re: can you see the future?
wander said: >Heh, you make this rise of light markup >sound like some kind of conquest... it _is_ a "conquest"... :+) and you would appreciate why i take that stance if you knew how many _years_ i spent in a war with some technocrats over at project gutenberg. they wanted to bog down that magnificent library with heavy-markup. their conflicts were whether it should be t.e.i. or docbook or x.m.l. or .xhtml. the only thing on which they could _agree_ was that i was crazy (and a troll) for advocating light-markup. so i had to battle against a big pack of technocrats, with no reluctance on their decision to turn vicious. of course their campaign was ridiculous on its face. even the academics who invented t.e.i. will tell you right out that it's extremely complex, even for them, so there's no way the volunteers at project gutenberg were going to master its intricacies and make it work. but technocrats -- like all other kinds of bureaucrats -- are full-blown idiots intent on bullying with their power, so these asswipes adamantly refused to see the obvious. thus i had to spent many years wiping their noses in it. so, yeah, for me, it _is_ a battle. has been, and will be. at least until there is a big groundswell of people asking "why do i have to convert my light-markup into .html? -- why doesn't the web-browser just do that automatically?" when _that_ happens, it'll be the coup de grace for all of the technocrats mucking up the simplicity of our future... and then i can take off my suit of armor... ;+) *** >Marked (looked at it, but decided it's too expensive) dude! it's $2.99! *** >I don't get your stance on PDF, though, bowerbird. .pdf is fine -- as an _output_ format. if you like it, great. as an _archival_ format, however, it stinks like a skunk... >It's my format of choice for keeping documents that >have a layout I spent time on. PDF does that pretty well. well, yes, .pdf does _that_ pretty well. right up until you decide you want to _change_ or _rearrange_ that layout... then -- if you don't have the original file, meaning you must repurpose the text inside the .pdf -- you're plumb outta luck. which is precisely why .pdf is _not_ a good archival format... *** fletcher said: >I am thinking about releasing this as an app on the Mac App Store. >Because of that, I won't be pushing any more updates to >the github repo, but I also won't take down what's already there. i can see you not wanting to give away the code... but since you were getting under 50 downloads, i'd think you'd still wanna share the compiled app. maybe you feel like you need the money, though... (the question: "what do you call a programmer without a girlfriend?" -- the answer: "homeless".) just so you all know, though, i've got my own app, and mine will be cost-free... i've been waiting for y'all to move your own circle forward a little more before i released my app, but i guess it's time now. perhaps you don't think of z.m.l. as your competition (why would you?), but i still thought i should tell you... -bowerbird___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net http://six.pairlist.net/mailman/listinfo/markdown-discuss
Re: can you see the future?
I've integrated direct support for Marked in my app, making it easy to use. Over the last day, I've made some really big leaps in usability for creating MultiMarkdown *or* Markdown documents. A few of those features were pushed to the github repo this morning. But it's really hitting an exponentially higher level of usability: * Automatic exporting from MMD (or even MD) to HTML, LaTeX, OPML, Flat OpenOffice Document Format (IMHO better than RTF in most ways, but easily converted to RTF by LibreOffice/OpenOffice) * Opens OPML as if they were hierarchical MMD/MD documents and lets you edit them as is (there are a few limitations to this "round-tripping" that I have mentioned before, but it's handy if you like OmniOutliner) * Bold/Italic support * Support for "paired symbols" - e.g. "[]" "()", double quotes, "``" * dropped files enter the file path - useful for linking to images, etc * a toggle that reverts to "plain" Markdown instead of MultiMarkdown I have a few more automation features I want to implement (basically the sorts of things I implemented in my TextMate bundle) * easier list creation and modification (indent/outdent, move up/down, etc) * automatic closing hash tags on headers (e.g. add the trailing "##" to h2's) Most importantly - I want an embedded version of peg-multimarkdown that doesn't rely on another installation. Currently, it uses the currently installed mmd 3. I know there are issues with compiling and my installer on older versions of processors and the OS. Because this looks like it really is going to go from a quick proof of concept to an actual application, and hopefully *the* MMD/MD centered application I have been waiting on for years, I am thinking about releasing this as an app on the Mac App Store. Because of that, I won't be pushing any more updates to the github repo, but I also won't take down what's already there. As I make a bit more headway, I'll be looking for beta testers (it's currently in more of an alpha/pre-alpha, though it works pretty well for the features that are implemented.). So the flurry of daily (and more than daily) updates will subside for a while as I go behind the curtain for a bit. F- On Jul 14, 2011, at 3:17 PM, bowerb...@aol.com wrote: > fletcher started work on an editing app > with markdown-preview built right in, > after reporting on his blog that he had > "seen the future" in ali's post last month, > where ali debuted his syntax highlighter, > and fletcher is releasing versions daily... > > > http://fletcherpenney.net/2011/06/ive_seen_the_future > > https://github.com/fletcher/MMD-Edit/downloads -- Fletcher T. Penney fletc...@fletcherpenney.net ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net http://six.pairlist.net/mailman/listinfo/markdown-discuss
Re: php-markdown-extra-extended - my humble attempt at extending php-markdown
I guess it is always a case of keeping Markdown "pure" or adding
support for attributes/classes when it is practical.
In my scenario, I had a customer who did not like to use any HTML in
their input, but still wanted to be able to tell the CMS back-end that
a specific paragraph was a disclaimer, that a specific paragraph
should be centered, that an image should be left or right floated,
etc. So the solution was to use the syntax {disclaimer} after a
paragraph, or {center}, {left}, {right}.
Its a compromise, that stays true to the Markdown syntax, and don't
introduce a new confusing html syntax in the mix.
That was my original motivation.
- Egil
> The rule of thumb I try to follow when doing extensions can be found
> at the very top of the Markdown project page
> (http://daringfireball.net/projects/markdown):
>
> "Markdown is a text-to-HTML conversion tool for web writers. Markdown allows
> you to write using an easy-to-read, easy-to-write plain text format, then
> convert it to structurally valid XHTML (or HTML)."
>
> I do not think that the :{ words } extension is easy to read or write.
> And I can't see how claiming it's the Latest Craze in Port Royal (tm Capt
> Bogg & Salty) addresses those concerns. If I want power, why shouldn't I
> just write a chunk of raw html? Markdown supports that natively and it's
> no less readable than :{ words } is.
>
> -david parsons
> ___
> Markdown-Discuss mailing list
> Markdown-Discuss@six.pairlist.net
> http://six.pairlist.net/mailman/listinfo/markdown-discuss
>
___
Markdown-Discuss mailing list
Markdown-Discuss@six.pairlist.net
http://six.pairlist.net/mailman/listinfo/markdown-discuss
Re: can you see the future?
Heh, you make this rise of light markup sound like some kind of conquest...
Anyway, both Byword (bought it, used it) and Marked (looked at it but
decided it's too expensive) seem like great apps and good additions to the
Markdown ecosystem.
I don't get your stance on PDF, though, bowerbird. I wouldn't call PDF a
scourge. It's my format of choice for keeping documents that have a layout I
spent time on. PDF does that pretty well.
Cheers,
Wander
On Thu, Jul 14, 2011 at 21:17, wrote:
> looks like my message from last week
> about writing tools was right on time...
>
> we are enjoying a display of fireworks
> now going off in this particular arena...
>
> fletcher started work on an editing app
> with markdown-preview built right in,
> after reporting on his blog that he had
> "seen the future" in ali's post last month,
> where ali debuted his syntax highlighter,
> and fletcher is releasing versions daily...
>
> > http://fletcherpenney.net/2011/06/ive_seen_the_future
> > https://github.com/fletcher/MMD-Edit/downloads
>
> further, there are now many more apps
> for the ipad/iphone which use markdown,
> compared to when i looked a month ago.
>
> i've bought almost all of them, and found
> that none of them hits the sweet spot yet,
> but some of 'em are getting kinda close...
>
> and really, what i'm looking for isn't hard,
> so i'm sure someone will get there soon...
>
> in the meantime, there's experimentation:
> >
> http://www.tuaw.com/2011/06/17/paragraft-gets-ios-markdown-editing-right/
>
> ***
>
> markdown support on desktop machinery
> is also increasing, as has been noted here:
> > http://www.tuaw.com/2011/05/23/byword-1-2-now-with-markdown-support/
>
> since most writers still write at their desks,
> that kind of support continues to be vital...
>
> ***
>
> the articles at those last two links are by
> brett terpstra, who's also just released an
> overarching tool that can be set to "watch"
> (i.e., monitor) markdown files (i.e., .txt files)
> output from other programs, and re-convert
> 'em to .html each time they are re-saved, so
> -- with this tool -- _every_ text-editor can
> now be described as "markdown-compatible".
>
> an auto-converter, itself, isn't a big deal, but
> terpstra's app -- "marked" -- also provides a
> preview pane of its conversion, making such
> "markdown support" more than a line of hype.
>
> that is, it can be run simultaneously with the
> other text-editor program, thereby giving you
> "instant feedback" if your results are incorrect,
> while you are still in the text-editor to fix 'em.
> this is an extremely valuable pedagogical asset.
>
> "marked" has other charms too. (for instance,
> it generates .pdf output which is serviceable.)
>
> and yes, it has glitches too -- some characters
> cause it to go blank, and (worst of all, for me)
> it seemingly will not handle files which do not
> have an extension (and none of mine do) --
> but it _is_ brand new, so we hope it improves.
>
> there are, however, some problems inherent
> in this approach. i execute saves _frequently_
> -- on the order of once a minute, i'd guess --
> but i'd like to see a re-rendering more often
> than _that_. but i just can't see how "marked"
> would ever be able to provide that. moreover,
> it'd be nice, when writing more than a snippet,
> if the display anchored at the insertion-point,
> not always presented from the top of the file.
> "marked" _could_ take measures to implement
> that feature, but i'm uncertain its programmer
> will see the need, or feel the feature is worth it.
>
> so i believe a light-markup text-editor which
> embeds its own output-display will be better.
>
> but despite these few shortcomings, "marked"
> is clearly a step forward in the right direction.
> and gruber sent its site 10,000 hits yesterday,
> and hopefully terpstra enjoys a great payday...
> ("marked" is now in the top-10 of paid apps.)
>
> so even in the mere week since my last post
> on this topic, things have improved greatly...
>
> yes, it's true that most of this improvement is
> occurring on the mac side, when light-markup
> is a benefit that can truly work cross-platform.
> (face it, folks, it's truly the only way that we can
> rid the world of the scourge known as ms-word.)
>
> and yes, it's also true that there's still too much
> emphasis on light-markup as a vehicle to .html,
> instead of enlightenment about its broader value
> for archiving, as an alternative to heavy-markup.
> (face it, folks, it's truly the only way that we can
> rid the world of that other scourge, called .pdf.)
>
> but given the last month, especially the last week,
> i'd think we can be quite happy with the progress...
>
> light-markup is on the march...
>
> -bowerbird
>
> ___
> Markdown-Discuss mailing list
> Markdown-Discuss@six.pairlist.net
> http://six.pairlist.net/mailman/listinfo/markdown-discuss
>
>
___
Markdown-Discuss mailing list
can you see the future?
looks like my message from last week
about writing tools was right on time...
we are enjoying a display of fireworks
now going off in this particular arena...
fletcher started work on an editing app
with markdown-preview built right in,
after reporting on his blog that he had
"seen the future" in ali's post last month,
where ali debuted his syntax highlighter,
and fletcher is releasing versions daily...
>http://fletcherpenney.net/2011/06/ive_seen_the_future
>https://github.com/fletcher/MMD-Edit/downloads
further, there are now many more apps
for the ipad/iphone which use markdown,
compared to when i looked a month ago.
i've bought almost all of them, and found
that none of them hits the sweet spot yet,
but some of 'em are getting kinda close...
and really, what i'm looking for isn't hard,
so i'm sure someone will get there soon...
in the meantime, there's experimentation:
>
http://www.tuaw.com/2011/06/17/paragraft-gets-ios-markdown-editing-right/
***
markdown support on desktop machinery
is also increasing, as has been noted here:
>http://www.tuaw.com/2011/05/23/byword-1-2-now-with-markdown-support/
since most writers still write at their desks,
that kind of support continues to be vital...
***
the articles at those last two links are by
brett terpstra, who's also just released an
overarching tool that can be set to "watch"
(i.e., monitor) markdown files (i.e., .txt files)
output from other programs, and re-convert
'em to .html each time they are re-saved, so
-- with this tool -- _every_ text-editor can
now be described as "markdown-compatible".
an auto-converter, itself, isn't a big deal, but
terpstra's app -- "marked" -- also provides a
preview pane of its conversion, making such
"markdown support" more than a line of hype.
that is, it can be run simultaneously with the
other text-editor program, thereby giving you
"instant feedback" if your results are incorrect,
while you are still in the text-editor to fix 'em.
this is an extremely valuable pedagogical asset.
"marked" has other charms too. (for instance,
it generates .pdf output which is serviceable.)
and yes, it has glitches too -- some characters
cause it to go blank, and (worst of all, for me)
it seemingly will not handle files which do not
have an extension (and none of mine do) --
but it _is_ brand new, so we hope it improves.
there are, however, some problems inherent
in this approach. i execute saves _frequently_
-- on the order of once a minute, i'd guess --
but i'd like to see a re-rendering more often
than _that_. but i just can't see how "marked"
would ever be able to provide that. moreover,
it'd be nice, when writing more than a snippet,
if the display anchored at the insertion-point,
not always presented from the top of the file.
"marked" _could_ take measures to implement
that feature, but i'm uncertain its programmer
will see the need, or feel the feature is worth it.
so i believe a light-markup text-editor which
embeds its own output-display will be better.
but despite these few shortcomings, "marked"
is clearly a step forward in the right direction.
and gruber sent its site 10,000 hits yesterday,
and hopefully terpstra enjoys a great payday...
("marked" is now in the top-10 of paid apps.)
so even in the mere week since my last post
on this topic, things have improved greatly...
yes, it's true that most of this improvement is
occurring on the mac side, when light-markup
is a benefit that can truly work cross-platform.
(face it, folks, it's truly the only way that we can
rid the world of the scourge known as ms-word.)
and yes, it's also true that there's still too much
emphasis on light-markup as a vehicle to .html,
instead of enlightenment about its broader value
for archiving, as an alternative to heavy-markup.
(face it, folks, it's truly the only way that we can
rid the world of that other scourge, called .pdf.)
but given the last month, especially the last week,
i'd think we can be quite happy with the progress...
light-markup is on the march...
-bowerbird___
Markdown-Discuss mailing list
Markdown-Discuss@six.pairlist.net
http://six.pairlist.net/mailman/listinfo/markdown-discuss
Re: php-markdown-extra-extended - my humble attempt at extending php-markdown
> That's actually what Jonh Gruber proposed a while back when he was
> still participating on this list. In his view, only {ref} was
> allowed, you couldn't specify attributes directly inline.
Thanks, I couldn't find that thread either and I forgot that he didn't like
inline attributes. I see no reason to forbid them. Writers will find a way to
produce hideous texts without or without such hand holding; better to put
simple assignments inline and use references as appropriate.
askye
___
Markdown-Discuss mailing list
Markdown-Discuss@six.pairlist.net
http://six.pairlist.net/mailman/listinfo/markdown-discuss
Re: php-markdown-extra-extended - my humble attempt at extending php-markdown
On Thu, Jul 14, 2011 at 12:47 PM, David Chambers
wrote:
> Albert Skye wrote:
>>
>> This paragraph has an attribute list attached by reference.
>>
>> {ref}
>>
>> [ref]: #id .class name=value
>
> This strikes me as an elegant solution to the problem, askye. Does anyone
> know of an extension that uses this syntax?
>
Maruku does (almost) [1] as a part of there attribute list syntax.
Basically, any single word (not a key=value pair or not starting with
a `#` or `.`) is treated as a reference. I have not implemented this
part in my implementation, mostly because I wasn't convinced that
Maruku's reference syntax was right.
[1]: http://maruku.rubyforge.org/proposal.html#using_tags
--
\X/ /-\ `/ |_ /-\ |\|
Waylan Limberg
___
Markdown-Discuss mailing list
Markdown-Discuss@six.pairlist.net
http://six.pairlist.net/mailman/listinfo/markdown-discuss
Re: php-markdown-extra-extended - my humble attempt at extending php-markdown
Albert Skye wrote:
This paragraph has an attribute list attached by reference.
>{ref}
>[ref]: #id .class name=value
This strikes me as an elegant solution to the problem, askye. Does anyone
know of an extension that uses this syntax?
David
On 14 July 2011 03:53, Michel Fortin wrote:
> Le 2011-07-14 à 6:01, Albert Skye a écrit :
>
> >> [1]: http://maruku.rubyforge.org/proposal.html#attribute_lists
> >
> > I don't understand why the leading colon should be present.
> >
> > In any case, it seems reasonable to:
> >
> > - enclose attributes in braces (to indicate text meant for
> authors/editors rather than readers)
> > - append attributes to elements (where they are likely to be somewhat
> less hideous)
> > - use whitespace before the attribute lists for block elements (up to one
> blank line)
> > - use conventional syntax
> >
> > This paragraph has an attribute list attached by reference.
> >
> > {ref}
> >
> > [ref]: #id .class name=value
> >
> > Am I missing something?
>
> That's actually what Jonh Gruber proposed a while back when he was still
> participating on this list. In his view, only {ref} was allowed, you
> couldn't specify attributes directly inline. It's not that easy to find the
> old emails, but I clearly remember it.
>
>
> --
> Michel Fortin
> michel.for...@michelf.com
> http://michelf.com/
>
>
>
> ___
> Markdown-Discuss mailing list
> Markdown-Discuss@six.pairlist.net
> http://six.pairlist.net/mailman/listinfo/markdown-discuss
>
___
Markdown-Discuss mailing list
Markdown-Discuss@six.pairlist.net
http://six.pairlist.net/mailman/listinfo/markdown-discuss
Re: php-markdown-extra-extended - my humble attempt at extending php-markdown
Le 2011-07-14 à 6:01, Albert Skye a écrit :
>> [1]: http://maruku.rubyforge.org/proposal.html#attribute_lists
>
> I don't understand why the leading colon should be present.
>
> In any case, it seems reasonable to:
>
> - enclose attributes in braces (to indicate text meant for authors/editors
> rather than readers)
> - append attributes to elements (where they are likely to be somewhat less
> hideous)
> - use whitespace before the attribute lists for block elements (up to one
> blank line)
> - use conventional syntax
>
> This paragraph has an attribute list attached by reference.
>
> {ref}
>
> [ref]: #id .class name=value
>
> Am I missing something?
That's actually what Jonh Gruber proposed a while back when he was still
participating on this list. In his view, only {ref} was allowed, you couldn't
specify attributes directly inline. It's not that easy to find the old emails,
but I clearly remember it.
--
Michel Fortin
michel.for...@michelf.com
http://michelf.com/
___
Markdown-Discuss mailing list
Markdown-Discuss@six.pairlist.net
http://six.pairlist.net/mailman/listinfo/markdown-discuss
Re: php-markdown-extra-extended - my humble attempt at extending php-markdown
> [1]: http://maruku.rubyforge.org/proposal.html#attribute_lists
I don't understand why the leading colon should be present.
In any case, it seems reasonable to:
- enclose attributes in braces (to indicate text meant for authors/editors
rather than readers)
- append attributes to elements (where they are likely to be somewhat less
hideous)
- use whitespace before the attribute lists for block elements (up to one blank
line)
- use conventional syntax
This paragraph has an attribute list attached by reference.
{ref}
[ref]: #id .class name=value
Am I missing something?
askye
___
Markdown-Discuss mailing list
Markdown-Discuss@six.pairlist.net
http://six.pairlist.net/mailman/listinfo/markdown-discuss
Re: php-markdown-extra-extended - my humble attempt at extending php-markdown
> (http://daringfireball.net/projects/markdown): > > "Markdown is a text-to-HTML conversion tool [...]" That may be its author's vision. In any case, it's a pity that so many seem limited by such. For some, Markdown is (or at least implies) much more than that, and remains useful with or without HTML. askye ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net http://six.pairlist.net/mailman/listinfo/markdown-discuss
