Re: Emacs as word processor

["Stephen J. Turnbull" <stephen@xemacs.org>]

Pascal J. Bourguignon writes:

 > - define a page size + page margins for the document.

-1.  That should a function of printing (including previewing final
copy).  Just text width.  The interaction between page sizes and
margins is quite complex if you want a good-looking and readable page.

 > - define header, body and footer areas of the pages.

+1.  But see below for comments on how that would be done.

 >   They can be specified with versions for odd and even pages,

-0.5.  Just mirror the format for odd pages if you want the even pages
to be different.

 >   and with alternate versions for pages beginning chapters or
 >   sections.

-1.  Way unnecessary for the first cut.

 >   Since headers and footers can be edited with styles too, editing them
 >   would have to call up secondary WYSIWIG windows.

-1.  Just edit them in-place, and when leaving that area prompt for
whether it's that page only, or change the style for all pages.

 > - define styles, apply styles to tags.

+1

 > - assign parenthesized tags to text ranges (in a hierarchical structure
 >   similar to SGML).

??

 > - define a file format.  I'd propose SGML with a DTD usable by docbook
 >   for the data, extended with as metadata a description of the document
 >   layout (page size, styles, etc).  Perhaps DocBook XSL (style sheets)
 >   could be used for the metadata.

You're proposing yet another file format that would be useless for
exchange with non-Emacs users?  I don't see the point.

 > - then for the WYSIWIG aspect, we'd need to implement a rendering
 >   engine.  We have the basis with font faces, but more work is needed to
 >   give a WISIWIG representation of the page, and its computed layout.

-0.5.  All you really need is leading for the interword spaces when
presenting fully justified text.  I don't think Richard is thinking
about photorealistic display (which you can't get anyway, even Word
sometimes prints differently from what you see on screen).

 >   Scrolling and zooming would behave differently in those WISIWIG
 >   windows, since they're would contain essentially a graphic
 >   representation of the page, like when we render PDF files.

-1.  No, PDF is static, not editable.  If there's reason do movement
differently in WYSIWYG editing buffers, probably the option should be
available in all editing buffers.  But I don't really see this as
necessary at first.

 >   Page margins, paragraph margins (set in the paragraph style), and
 >   other elements could have graphical controllers overlaid for GUI
 >   interaction, as well as being editable with normal keyboard commands,
 >   like the scroll-bar, menu-bar and tool-bar options.

-1.  Way unnecessary for the first cut.

 > The reason why people have so much a hard time to use and apply
 > styles with word processors: they presence and definition is
 > hidden, since they're not "printed out", only their effect is
 > visible.

This is a Microsoft conspiracy to sell classes in Word use, I think.
The things that regular people need to do with styles in a simple
wordprocessor are relatively few.

 > A solution in emacs could be to use a second window, a metadata window
 > (a little like a minibuffer, but probably bigger), that would appear
 > automatically when editing a WYSIWIG window, so that when moving the
 > cursor on a cell in the WYSIWIG window, style and other metadata can be
 > displayed in the metadata window, and editing commands can then be given
 > that modify the metadata and are reflected WYSIWIGLY in the WYSIWYG
 > window.

-100 (maybe more).  Either you want to edit a markup language (a la
CSS) "out of band", or make changes GUI-ly.  Either way, we don' need
no steenkin' metadata windows getting in the way of a bigger picture
for the document we actually care about.

 > When you edit plain text, or plain text with markup (either "implicit"
 > thru formating like in reStructured Text or markdown, or tagged text in
 > the SGML family), you use the same command set to edit both the data and
 > the metadata.  Even to edit both at the same time!  
 > 
 >     M-x replace-string RET <p>The RET <br>And the RET
 > 
 > But in the case if a WYSIWIG word processor, as long as we don't provide
 > a plain text data+metadata buffer to be edited in emacs as plain text,
 > we need to define two sets of commands,

I really don't see this.  When you're in a "cell" (header, footer,
body, object == table, figure), you should be able to edit that cell
directly, and have it reflected in the stylesheet without special
commands.  Yes, there will be special commands because the _content_
of specials is different (instead of a literal numeral, there will be
a "page_number" object in headers and footers, for example, and
selecting from the available objects -- including the non-portable
"sexp" of course!!).  So we will require a special insert command, but
not much more, I suspect.

 > And this is the fundamental problem with word processors and WYSIWIG
 > editors.  Since data and metadata is separated, a text editor becomes
 > useless to work on them.

Metadata will be applied via text properties and overlays, no?  I
don't see a real difference between that aspect of the current Emacs
buffer/redisplay model, and what you're talking about here.

 > So the bet here is that adding a new set of commands to edit the
 > metadata could be done in a way that's sufficiently practical and usable
 > to make editing WYSIWIG document a little more agreable than editing
 > plain tagged text (SGML, reStructuredText, LaTeX, etc).

I suspect all this is quite far from what Richard is thinking about at
this point.  I understand what he wants (as a first cut) to be
something like

    position cursor before the words "emphasize this text"
    type M-3 M-@ C-c C-f C-e
    see "emphasize this text" in italics

(Aside to Richard: the key sequence C-c C-f C-e is compatible with
AUCTeX, which uses C-c C-f as a common prefix for face-changing
commands: emphasize, italic, bold, typewriter, ....  Perhaps it would
be nice to make the "M-@" implicit -> C-3 C-c C-f C-e.)

Next step would be continuous leading for full justification.

Probably after that add very simple header and footer capability, with
a fixed number of lines per page (possibly using a very simple
modeline-like format spec?)  [Personally, I prefer to think of each
chapter as a long scroll, and editing doesn't care about headers/
footers.  YMMV of course, but that point of view suggests that
headers, footers, and WYSIWYG pagination in general can come later
than the within-page stuff.]

The following step would be text that flows around objects (tables,
figures).

And all the while we think about how to add complex capability without
adding complex UI. :-)

All above is IMHO YMMV IANAL TINLA etc....

Steve