Earlier quoted context omitted.
I prefer the paradigm where you edit in something like markdown but the live preview is available on the right hand side or down below the text. All it needs is a catchy acronym. The controls for the text should be immediate in the text, that makes sense and is the most powerful implementation. But you have to see what it all means and be able to identify problems along the way when you make a mistake & know what you…
I think this is usually called What You See Is What You Mean, or WYSIWYM. However, there could be a performance problem. Font setting and layout in Latex is markedly superior to, say, web browsers or Word. But Latex often takes several seconds to lay stuff out. Then again, Indesign can do it, so it should be possible in general.
without performance problems.
markdown has several such solutions, online and off. the offline apps are typically mac, the leaders being "marked" (marked2.com) which works with any text-editor, and "multimarkdown composer" (multimarkdown.com), which wraps a dedicated-editor around the conversion-routine.
i will soon be introducing my own light-markup system -- z.m.l. (zen markup language) -- and will offer apps which are cross-platform offline, as well as web-apps, including one with an a.p.i. that can be used by anyone. send it a light-markup .zml file; it sends back .html.
for a similar online solution for markdown, see here: http://markdownrules.com
and this is where stallman's request has gone awry...
namely, you don't need to wrap the conversion-routines into the app, or change the interface of the app at all.
instead, simply route your light-markup plain-text file to a converter, and show the output in a preview window. and yes, it should be side-by-side with your editor and show the changes in real-time as you make (or save) them.
my light-markup system differs from markdown in that it: 1) is targeted at long-form documents, such as books, 2) avoids the problems which plague markdown, 3) focuses on lightness as an asset that _eases_editing_, rather than as something that _fosters_readability_of_the_raw_format_ (as there's no reason to read the file in that raw format).
speaking of readability, as well as my focus on long-form, .html is not the only output format supported by my system; we also need .epub, .mobi, .pdf, and still-to-come formats.
the other important thing about z.m.l. is that its focus on _books_ shines a different focus on needed functionality, compared to that provided by generation of a mere web-page.
all this and even more, coming before thanksgiving day...
-bowerbird