fletcher said:> > If you're working on a long document,
> > it's not realistic to expect an as you type live preview -
> > the performance just won't be there.
i said:> i'll wait to challenge you on this assertion until i see
> just exactly how well my app works in such situations.
i've now done tests, and can conclusively say it isn't true.
not as far as my analysis engine in my program, anyway...
i knew that before, but i wasn't using the hardest case --
a very long document where the entire file was rendered.
but i tested a book that's over 900k, over a meg in .html,
rendered it in its entirety, centered at the cursor-location,
and saved the file to disk, all in seconds, on an older mac.
that's faster than it needs to be, considering that display
of the full book isn't even desirable, let alone necessary.
plus that's without using any of the tricks i'd thought up...
so this question has now been answered unequivocally.
***
thus, i'm gonna end my discussion of on-the-fly display...
i think i've been convincing in making the case for it, and
people here are free to implement it or not, as they see fit.
so i'll go to the next mountain for markdown to climb up.
and surprise, surprise, but aaron swartz got there first.
(really, i ask you, is there _anything_ this kid didn't do?)
because the next mountain is back-conversion to markdown.
conversion from markdown into .html is easy, easy enough
that 249 people have variants of a program that can do it...
and yes, probably 237 of 'em produce different results, but
the point is that markdown-to-html just isn't that difficult...
so let's move ourselves forward to back-translation, shall we?
and, of course, the prior art for markdown is
"html2text":> http://www.aaronsw.com/2002/html2text/
by aaron. and it dates to 2002. but it probably still works ok,
because -- as the page shows -- it's constantly being updated.
indeed, the latest version appears to be hosted on github, with
the latest file with a mod-date of just two days ago! who knew?
we _might_ do better, though. so cut to the pan-doc
chase:> http://johnmacfarlane.net/pandoc/
pandoc is fantastic. no two ways about it. just fantastic.
this software can cross-convert 183 types of light-markup.
hey, i bet you didn't even _know_ that 183 types _existed_!
well, pandoc does, and it's got every one of 'em down pat...
you'll be hard-pressed to find anything more remarkable.
nonetheless, i felt a lot more sanguine about pandoc when
i was under the misimpression it supported multimarkdown.
because without a solid authoring tool for its own format,
i think pandoc is gonna twist in the wind. sorry, john, but
that's my opinion. (and, just so everyone is clear on this...
at one time i offered to write an authoring tool for pandoc.
if john would've offered to write the z.m.l. converter for me,
i would have. still will. but he told me i had to do it myself.
and use haskell. and i still haven't had to time learn haskell.)
i say pandoc is the greatest thing out there. i want it to win.
i'm just not sure that it will.
so that leaves us with a couple of newcomers to the game...
the first is "fuck yeah markdown", which i mentioned
earlier.> http://fuckyeahmarkdown.com/
or, if you prefer, the g-rated version is located here:> http://heckyesmarkdown.com/
i haven't played with it yet, but it looks like a straightforward
html-to-markdown converter, so it's not all that interesting...
ok, i lied. it's actually very interesting. first of all, it's from
brett terpstra, who did "marked", and is quickly turning into
markdown's best friend. second, it's based on "readability",
which tosses the garbage out of webpages while keeping the
crunchy text goodness, so that makes this cool and exciting.
third, because brett is a nerd, the converter is also available
in bookmarklet form, _and_ there is an a.p.i. interface too...
a whole lotta stuff to put behind a u.r.l. bearing the f-word.
so there's much look at with this first newcomer to the game.
the second is interesting too, maybe even more fascinating,
i'm not sure, since i haven't really played with it much either.
it's emmanuel's converter:> http://akaya.me/
what's potentially extremely exciting here is that it appears
-- on first glance, which is about all that i have given it --
that emmanuel's converter takes a broader range of input.
specifically _including_ text that came out of a text-editor.
which, obviously, was _not_ markdown text to begin with,
since it ain't too hard to convert markdown to markdown...
but converting raw text into markdown? that'd be _great_.
and it is precisely that task which is "the next mountain"...
here's how i put it recently, in a comment on a blog article:
> i wanna throw some barely-formatted content in the
> machine, and have the computer make it beautiful,
> flexible to any change in its underlying canvas...
>
>
http://www.webdirections.org/blog/the-challenge-of-wysiwyg-development-for-the-web/
back-translation is one thing. but if you already had to
do the formatting in one system, it's not that big a deal
to get it converted into another system. you still had to
do the work in the first place. i don't wanna do the work.
i want the computer to do it for me, and do it just as well
-- heck, preferably _better_ -- than i would have done it.
back-conversion is the "base-camp" for the next summit,
which is to convert unformatted text into nice markdown,
such that the output looks beautiful and _validates_ too...
and yes, that means we've got some "artificial intelligence"
that can mimic a designer (and therefore must create art),
as well as be wise as to the "semantics" of the document
-- where "semantics" really means the structural elements,
and i use the air-quotes to show that i know that people
who use this term really don't know what it actually means,
but they continue to flaunt it (or is it flout it?) anyway --
and yes, i do realize this is an "impossible" task, i do, but...
that is "the next mountain", folks... who wants to climb it?
-bowerbird
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://six.pairlist.net/pipermail/markdown-discuss/attachments/20111027/1528b231/attachment.html>
