doesn't that make you wonder?

[Emmanuel Bégué]

Many thanks for your input. Answers below.

2011/10/16  <Bowerbird at aol.com>:

> so here's the "bad" section...

>

> it would be better if you had a combination of offline/online.

> the only approach i see prevailing long-term will _use_both_.


The goal is for this app to run offline; it's actually pretty easy to
do but will only work with recent browsers.

In fact, I'm thinking of making it a Chrome app (that would therefore
only work in Chrome), which would solve a lot of problems, including
offline mode and file management issues; the Chrome browser is
available for all platforms but there are corporate entities that
flat-out refuse to use it,  so I'm not sure about this yet, but this
is where I'd like to go.

Once I figure out if I go the Chrome route or not, I'll add offline
capabilities.



> on "file management", i guess i'm old-fashioned, but i want to

> know where the file is, be able to do direct manipulation on it,

> edit it in another app, run my own spellcheck tools on it, etc.

> i see where i can "download" the markdown file, but that would

> then just be a copy of the actual "file", not the document itself.

> i'm also unclear on where the actual "file" resides.  is it in the

> offline cache for that specific browser?


Yes (localstorage).



> -- in which case even

> another browser on my own machine won't be able to get to it?

> as there's no log-in, it can't be stored "in the cloud", meaning

> that i certainly cannot get to it while using another _machine_,

> thus removing a lot of the functionality of having a web-app...

> confusions like these are gonna lose the average user quickly.


It's also stored in the "cloud" (the cloud being the server that
serves the app).

There's "invisible" login: the first time you access the app you're
given a unique ID that is used to identify your documents (this id is
used in the documents' names when you download them).

For now the UI doesn't exist to download files to another browser, but
all the infrastructure is in place.

If the app were a Chrome app it would be easier because Chrome would
automatically sync localstorage without the user having to do anything
(and still not have to login!); that would be a big gain I think.

There's another "problem", though. I devised a "proprietary" file
format, which stores files as lists of diffs with a timestamp, so that
you can undo any change, even months later (the changes are right
there in the file and are never deleted). The undo functionality is
not coded in the UI yet.

But that means that the "raw" file is not usable by the user as-is,
nor is it usable by another program (although the diffs are stored in
common diff notation). It's a simple format but it's proprietary and
new: that's the bad part. I need to figure out if the good part (being
able to do infinite undos) offsets the bad part (having a special file
format).

I could also interface with Dropbox (I probably will); what I don't
want is to depend on Dropbox: to force users of my app have a Dropbox
account.



> so as far as i can see, your competition is "marked.app" and the

> still-forthcoming-but-any-day-now "multimarkdown composer".


They're both fantastic, but Mac-only, so I believe that leaves a big
part of the corporate world still open? (Although it's possible that
companies that know of Markdown, use Macs, and companies who use PCs
have never heard of it. ;-)

But the real innovation here, IMHO, is marked.app, which lets the user
choose her editor of choice; that's really great.

MultiMarkdown Composer, on the other hand, is less impressive: AFAIK
it doesn't do anything that a webapp couldn't do, so why download an
app that will only work on a specific platform?



> finally, we have your innovation -- showing the particular part

> actually being actively edited by the person at the current time.

>

> all the online converters show the .html starting at _the_top_,

> which is not what you want when you doing mid-doc editing,

> and this is the improvement which you brought, emmanuel...


That's actually what got me started to build this; I found all the
other webapps unusable after the first few paragraphs...



> (which, for the record, is not to say the solution was difficult.

> i worked it out for my program.  it does get a bit problematic

> when -- like "marked" -- you can't track the insertion point;

> but even then, the secret isn't that hard to figure out, so i am

> somewhat surprised that brett has not puzzled it out already.

> he'd simply have to save each version of the text in a variable,

> then compare it to the text the next time it is to be converted;

> the first point of difference is where he should focus display.)


That's not how I do it, because I need the current paragraph to be
highlighted when clicked on (ie, in the absence of any kind of
change). But I did try your approach first, and found out that you
need to detect changes in the resulting HTML, not the source Markdown.
For example, if you're editing a link by reference, you want to see in
the preview where the link is actually displayed, not the part you're
editing (which all but disappears in the preview).



> the "bad" part, emmanuel, is that your "preview" window is tiny.

> it needs to be bigger.  much bigger.  i like a display that splits

> the full browser window into an "edit" half and a "display" half.

> now maybe that's just me, but i suspect that everyone will need

> a preview window that's bigger than four or five lines of text...


I liked the small window but I get this remark a lot, so it's not just
you: rather, it's just me;-) I'll change it to a more traditional
split-screen approach.



> and now we go on to finish up with the "ugly" section...

>

> the problem is that there are many different markdown variants.

>

> these variants all handle the main simple stuff of markdown in

> the same way, because that main simple stuff is... well... simple.

>

> but they are "variants" because they all have their own wrinkles.

> none of them are consistent with each other, in the fine details,

> not in a dependable way, so it's impossible for them to "share".

> it _seems_ like "it works", because the main simple stuff works;

> but if you use a variant-specific capability, it'll explode on you.

>

> and now any text that a user creates in your system might give

> _inconsistent_results_ if the user takes it to some other variant.

>

> so if i were you, emmanuel, i'd use multimarkdown instead...


I agree that it looks likely that MultiMarkdown will win in the end
(is in the process of wining), and that it's the way to go.

[But is it really true that there are inconsistent results for what
may be called "Core Markdown" (as described in the original Gruber
posts)?]

My approach is this:

- my app needs to work offline
- I'd rather not code "yet another" Markdown parser (I actually gave
this some thought but eventually decided against it)
- therefore I need to find an existing Markdown parser **in
JavaScript** (not PHP, not C#, or Python, not a Ruby gem, etc.)
- of these, the "mainstream" one is PageDown (a descendant of
Showdown). There are many many people posting questions or answers on
one of StackOverflow's sites, so it's arguable to say that today, most
people know Markdown through PageDown; it also means that it's very
robust, being used everyday by thousands of people.

I can compromise on anything but the first item: the app needs to be
able to work offline without roundtrips to the server. If I find a
MultiMarkdown implementation that either is already in JS or can be
ported to it, or if I find the time and motivation to code one myself
(or just add Multi's extensions to PageDown), why not.

I did find Markdown Deep (http://www.toptensoftware.com/markdowndeep/)
but it's recent (not field tested) and has bugs; I raised an issue on
GitHub but got no answer, so maybe the project isn't actively
maintained.

If you have implementations to recommend I'd be happy to look into them.

Thanks again for the detailed comments.

Cheers,
EB

PS: did you look at the "converter"? Before your post (that I replied
to) I couldn't find anything like it anywhere.