<HTML><FONT FACE=arial,helvetica><HTML><FONT COLOR="#000000" FACE="Lucida Grande" LANG="0" SIZE="4">aristotle pagaltzis said:<BR>
&gt;&nbsp;&nbsp;  we can agree he has achieved more in three months <BR>
&gt;&nbsp;&nbsp;  than you have in a decade of talking.<BR>
i'm not sure who your "we" is, aristotle, but i guess this means<BR>
that you will not be doing alpha-testing for my new program...<BR>
how will i ever be able to manage without your valuable input?<BR>
but hey, maybe i'm wrong, and this list _has_ accomplished<BR>
something worthwhile and notable in the last three years...<BR>
if you believe it has, do please feel free to tell us what it was.<BR>
on the other side of the fence, however, i see lots and lots of<BR>
people who are doing things with markdown these days, but<BR>
only a very precious few even bother to come here and _tell_<BR>
this list what they are doing (and usually well after the fact),<BR>
and nobody -- and i mean absolutely nobody -- comes here<BR>
for _advice_ or "accumulated wisdom" or _anything_ like that.<BR>
heck, even _gruber_ doesn't bother to come here any more...<BR>
doesn't that make any of you people _wonder_?<BR>
emmanuel said:<BR>
&gt;&nbsp;&nbsp;  I made a Markdown editor webapp two weeks ago:<BR>
&gt;&nbsp;&nbsp;  http://akaya.me ("Yet Another Markdown Editor") <BR>
you've made a nice start, emmanuel, a nice start indeed.<BR>
here is my review of "the good, the bad, and the ugly"...<BR>
we'll start with the "good" section...<BR>
as far as the "good" goes, i like that you've made a web-app.<BR>
it's time to put the script-kiddies to bed; if installing a script<BR>
is part of your workflow, the general public will never buy it...<BR>
and the way your app is taking care of "file management" is<BR>
in tune with how the trend seems to be heading these days...<BR>
</FONT><FONT COLOR="#000000" FACE="Lucida Grande" LANG="0" SIZE="4"><BR>
moreover, the "yet another" name shows that you realize that<BR>
what you've done might be one in a big number of contenders;<BR>
it's good to have healthy expectations even if you dream big...<BR>
</FONT><FONT COLOR="#000000" FACE="Lucida Grande" LANG="0" SIZE="4"><BR>
finally, you've made an improvement in the achilles' heel of<BR>
_every_other_ on-the-fly converter, as far as i know, which is<BR>
that they don't show the point which is being actively edited.<BR>
except for this last point, all of the items in your "good" list<BR>
are mirror-imaged in the "bad" category, which is _curious_...<BR>
so here's the "bad" section...<BR>
first, the web-app part.&nbsp;  it is _good_ to have a web-app, but<BR>
it would be better if you had a combination of offline/online.<BR>
i understand the benefits of having something in the browser.<BR>
but native apps still have advantages, and likely always will...<BR>
the only approach i see prevailing long-term will _use_both_.<BR>
on "file management", i guess i'm old-fashioned, but i want to<BR>
know where the file is, be able to do direct manipulation on it,<BR>
edit it in another app, run my own spellcheck tools on it, etc.<BR>
i see where i can "download" the markdown file, but that would<BR>
then just be a copy of the actual "file", not the document itself.<BR>
i'm also unclear on where the actual "file" resides.&nbsp;  is it in the<BR>
offline cache for that specific browser? -- in which case even<BR>
another browser on my own machine won't be able to get to it?<BR>
as there's no log-in, it can't be stored "in the cloud", meaning<BR>
that i certainly cannot get to it while using another _machine_,<BR>
thus removing a lot of the functionality of having a web-app...<BR>
confusions like these are gonna lose the average user quickly.<BR>
this brings us to the thing about having lots of "competitors"...<BR>
i fully realize you might just be doing this project "for fun" and<BR>
not have aspirations of making it "big"...&nbsp;  but, at the same time,<BR>
you obviously know that a developer must do serious polishing<BR>
in order to take any project public in the way that you are doing.<BR>
having a base of users is what can make all that work worthwhile.<BR>
so you need to ask questions about what could make users come<BR>
to prefer your site over all of the other competing sites instead...<BR>
i don't have any answers; just telling you those are the questions.<BR>
as far as those "competitors" go these days, in my eyes you have<BR>
_two_ in particular that you'll need to stack yourself up against...<BR>
and no, google docs isn't one of them.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;  :+)<BR>
(people looking for a web-based editor should most certainly<BR>
consider google docs.&nbsp;  and they will do so, i am quite sure, but<BR>
if google docs makes 'em happy, no peons like us can compete.<BR>
we're splitting whatever scraps might fall off the google table,<BR>
as well as people who refuse to eat at that table on principle.)<BR>
and no, i don't consider all the other online-editing sites now<BR>
cropping up to be "your competition" either.&nbsp;  on the one hand,<BR>
yes, of course they are.&nbsp;  on the other hand, they are equivalent<BR>
to you, so there's no real good reason to prefer them over you.<BR>
not at the present time, anyway...<BR>
i feel much the same about all the ipad editing apps.&nbsp;  they show<BR>
great promise, and the might be competitors to you long-term,<BR>
but for the here-and-now, they'll still have to prove themselves.<BR>
so as far as i can see, your competition is "marked.app" and the<BR>
still-forthcoming-but-any-day-now "multimarkdown composer".<BR>
and yeah, both of those are offline entities, so you might think<BR>
that they can't compete, by definition.&nbsp;  but i'd say you're wrong.<BR>
first of all, let's grant that they are both _very_powerful_, in the<BR>
exact manner that we can expect offline applications to shine.<BR>
"marked" already has tons of fans, and the beta of "composer"<BR>
was more than enough to show the promise of _that_ program.<BR>
so they've already got the offline part of the equation down pat.<BR>
with dropbox and all the other cloud-sync tools available now,<BR>
every document can have the capability of being omni-present.<BR>
so that aspect of the web-app is increasingly being matched up.<BR>
it'd be good (for them, bad for you) if "marked" and "composer"<BR>
had online equivalents, but i don't think they're going to suffer<BR>
very much because of a lack of them.&nbsp;  one beauty of plain-text<BR>
is that you can work with it in any text-editor, and that is one of<BR>
the assets "marked" -- in particular -- uses to great advantage.<BR>
so i think, even now, "marked" and "composer" have _enough_<BR>
of a combination of offline/online power that they can succeed<BR>
over and above an approach that uses an online-only strategy...<BR>
but that's my opinion, and i could be wrong, so if you disagree<BR>
with it, and you are willing to bet on yourself, go right ahead...<BR>
finally, we have your innovation -- showing the particular part<BR>
actually being actively edited by the person at the current time.<BR>
it was good of you to recognize this obvious flaw in many (all?)<BR>
the current on-the-fly converters, and you found the answer...<BR>
first, though, let's do a quick review.<BR>
most of the "dingus-style" online converters -- up until lately --<BR>
have been severely limited, in that they don't accept much text.<BR>
although i wouldn't expect that it would be "difficult" to mount<BR>
one of the converter-scripts so that it would handle large files<BR>
(where, by "large", i mean a text-file in the range of 250k-750k,<BR>
which is the amount of disk-space required by a "typical" book),<BR>
as far as i know (please correct me if i'm wrong), _no_one_has_.<BR>
so i was pleasantly surprised to see that your site took a big file.<BR>
(the browser gave the "this script is taking a long time" message,<BR>
but i clicked "continue" and it completed successfully, so there.)<BR>
all the online converters show the .html starting at _the_top_,<BR>
which is not what you want when you doing mid-doc editing,<BR>
and this is the improvement which you brought, </FONT><FONT COLOR="#000000" FACE="Lucida Grande" LANG="0" SIZE="4">emmanuel</FONT><FONT COLOR="#000000" FACE="Lucida Grande" LANG="0" SIZE="4">...<BR>
"marked" recently added the ability to "anchor" the display to<BR>
the _bottom_ of the file, which is nice if you are adding text...<BR>
but if -- like me -- most of your writing is _rewriting_, then<BR>
most of the time you're working in the middle of a document.<BR>
and if you need to _scroll_ to see your "on-the-fly" preview,<BR>
it's really not all that "on-the-fly", if you know what i mean...<BR>
so emmanuel...&nbsp;  your achievement here is truly a worthy one.<BR>
(which, for the record, is not to say the solution was difficult.<BR>
i worked it out for my program.&nbsp;  it does get a bit problematic<BR>
when -- like "marked" -- you can't track the insertion point;<BR>
but even then, the secret isn't that hard to figure out, so i am<BR>
somewhat surprised that brett has not puzzled it out already.<BR>
he'd simply have to save each version of the text in a variable,<BR>
then compare it to the text the next time it is to be converted;<BR>
the first point of difference is where he should focus display.)<BR>
the "bad" part, emmanuel, is that your "preview" window is tiny.<BR>
it needs to be bigger.&nbsp;  much bigger.&nbsp;  i like a display that splits<BR>
the full browser window into an "edit" half and a "display" half.<BR>
now maybe that's just me, but i suspect that everyone will need<BR>
a preview window that's bigger than four or five lines of text...<BR>
and now we go on to finish up with the "ugly" section...<BR>
emmanuel, you might or might not know this, but one reason<BR>
that i say that this list hasn't "accomplished" anything in years<BR>
is that there has been a major problem confronting markdown<BR>
in that timeframe, and none of the responsible parties worked<BR>
to solve it.&nbsp;  oh, they would "discuss" it every once in a while, but<BR>
the discussion would fade to silence, and nothing ever got done.<BR>
the problem is that there are many different markdown variants.<BR>
these variants all handle the main simple stuff of markdown in<BR>
the same way, because that main simple stuff is... well... simple.<BR>
but they are "variants" because they all have their own wrinkles.<BR>
none of them are consistent with each other, in the fine details,<BR>
not in a dependable way, so it's impossible for them to "share".<BR>
it _seems_ like "it works", because the main simple stuff works;<BR>
but if you use a variant-specific capability, it'll explode on you.<BR>
it's very much like the inconsistencies of "the browser wars"...<BR>
you have inadvertently stepped into the middle of this "war",<BR>
without even knowing it, because it is impossible to avoid it.<BR>
when you chose the converter from "stack overflow", you made<BR>
a declaration of allegiance to that particular markdown variant.<BR>
and now any text that a user creates in your system might give<BR>
_inconsistent_results_ if the user takes it to some other variant.<BR>
and they probably will not even _notice_ this inconsistent glitch,<BR>
since they won't have felt a need to scrutinize every little thing...<BR>
so they will put their product out in the world with a glitch in it.<BR>
not the end of the world, no sir.&nbsp;  but not what they want, either.<BR>
how you choose to react to this ugly situation is your choice...<BR>
but perhaps the choice is more clear now than it might've been<BR>
-- oh, let's say -- six months ago.&nbsp;  because the logjam on the<BR>
"variant" problem certainly looks to me like it's going to clear...<BR>
up until now, each of the variants was roughly equivalent to<BR>
all of the other variants.&nbsp;  thus none of them had an incentive<BR>
to "back down" from the overall competition to "be the winner".<BR>
they could each hope that the other variants would choose to<BR>
"become compatible with the way i have decided to do things".<BR>
but "marked" and "composer" have upset that delicate balance.<BR>
in case you don't know, "marked" defaults to multimarkdown.<BR>
and yes, "multimarkdown composer" uses multimarkdown too,<BR>
so multimarkdown has surged into the lead, and that lead will<BR>
take a sharp hike upward when "composer" gets released soon.<BR>
if "composer" is allowed to retain the "first mover" advantage<BR>
for any length of time, the lead will become insurmountable...<BR>
so -- for the first time since markdown was first introduced --<BR>
we will all be able to count on a de facto markdown "standard".<BR>
will all of the variants -- including the stack-overflow one --<BR>
continue to exist?&nbsp;  probably.&nbsp;  but outside of their own venue,<BR>
they'll be largely ignored.&nbsp;  if you can't edit a file in "composer",<BR>
and have it act correctly, it won't be considered as "markdown".<BR>
and if it doesn't look right in "marked", it won't be "markdown".<BR>
as i said, i have programmed an editor with on-the-fly display<BR>
for my light-markup system -- zen markup language, z.m.l. --<BR>
and a while back, i asked a question on this list about _which_<BR>
markdown variant i should use if i were to program a routine<BR>
in my editing-program that would convert z.m.l. to markdown.<BR>
today, i wouldn't bother to even ask that question any more,<BR>
because the answer is very clear to me -- multimarkdown...<BR>
unless one of the other variants makes a _big_move_ very soon,<BR>
multimarkdown will be the winner within a year, at the longest.<BR>
so if i were you, emmanuel, i'd use multimarkdown instead...<BR>
</FONT><FONT COLOR="#000000" FACE="Lucida Grande" LANG="0" SIZE="4"></FONT></HTML>