Re: Emacs as word processor

[Hendrik Boom]

On Sun, 17 Nov 2013 02:28:51 -0500, Richard Stallman wrote:

> 25 years ago I hoped we would extend Emacs to do WYSIWG word processing.
>  That is why we added text properties and variable width fonts. 
> However, more features are still needed to achieve this.
> 
> Could people please start working on the features that are needed?

There is one reason that I use emacs for my writing.

The file structure is very compatible with modern distributed revision 
management systems.  (I use monotone).

When I edit stuff, only the bit I'm editing changes.  The rest stays the 
same.

I've introduced minimal mark-up, so that I can specify italics and such 
when I need them.  And I wrote a program to convert the (almost) plain-
text to .fodt so I can feed it into LibreOffice for a nice printout.

Maybe I should just have used asciidoc or markdown.  But when I  started 
on this stuff I didn't know about those tools, and maybe the didn't exist 
yet.

The main spec for this program is that it doesn't choke on *any* input, 
and does something reasonable with it whether it is nicely marked up or 
not.

I avoid large-scale bracketing structure as much as I can, because the 
merge tools used with revision control are terrible at preserving 
brackets.

I OpenOffice would place lots of line breaks in consistent places so that 
revision management would merge properly, .fodt's bracket structure would 
*still* be a problem, because LibreOffice chokes on bracket mismatch.

So in my markup, I assign operator priorities to separators -- like 
paragraphs, sections, and so forth.  The code is a mess, because I didn't 
realize this at first.  Everything will need to be rewritten a few times 
before my program does what I want and is really well-structured.  But 
hey, this is experimental (textual) UI programming, and you don't know 
what you want until you have it and it isn't it.

I wouldn't mind in the slightest if I were to be editing WYSIWYG and the 
word-processor were to save my data in an internal format that's amenable 
to revision management and automatic merging.  Especially if it avoids 
layout-specification overkill the way most word processors do.  I'm 
really interested in a document compiler where I specify structural 
matters and the word processor shows me how it might look on a page.  But 
the page layout shouldn't be definitive.  If I map it onto a different 
page size, it should reflow, adjust.  In fact, it might as well adapt 
itself to a scrolling resizable GUI window the way well-written HTML does.

What's needed for this?  A layout manager that constantly recalculates 
what should be in the screen as the text it's laying out changes.  And an 
editor-interface to that layout manager that does the usual editor 
commands as applied to the non-laid-out source code.

Well, actually, we should accept that a document is a data structure.  A 
data structure that's traditionally represented mapped onto a long string 
of characters, or as ink in paper in a particular style of arrangement.

It's a data structure just as much as a Lisp program is a data structure, 
traditionally represented either with pointers in RAM or as text with 
lots and lots of parentheses.

The underlying data structure is what we  want to edit.  It needs to have 
a representation that's amenable to revision control.  Possibly  every 
object in the data structure gets a persistent name (maybe a random
64-bit number) and the objects (paragraphs, sentences, chapters, 
etc) refer to each other by these names and the set of objects is written 
out in order, sorted by name.  With lots of newlines.

That should merge properly.

Anybody up for this?  The data structure could be reusable in completely 
different kinds of applications, not just word processing.  It could be 
manipulated with different views, ones "showing codes" as WordPerfect 
used to so, ones that WYSIWYG, whatever.

I don't know if any of this is like what emacs does internally.

I don't know if anyone has built a mergeable object store like this.

-- hendrik