Re: Emacs as word processor

[Pascal J. Bourguignon]

Richard Stallman <address@hidden> writes:

> I mean a simple way to put some text in a different font, such as a
> 14-point bold font for a title, and have it (1) display on the screen
> in that font and (2) have that markup saved in the file.
>
> Emacs can already display a piece of text in that font, but it lacks a
> convenient user-level feature to do this whole job.

So, let's start some specifications for an emacs wordprocessing-mode.

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

- define header, body and footer areas of the pages.  They can be
  specified with versions for odd and even pages, and with alternate
  versions for pages beginning chapters or sections.  They can also
  contain dynamic parts (eg. foot notes from text laid out on a page may
  be inserted in the footer of the page).

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

- define styles, apply styles to tags.

- 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.

- 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.
  
  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.

  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.
  

One problem is that there are parts that have a lot of editable
metadata, but which are not represented at all in a WYSIWIG document.
That's 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.

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.



In terms of user interface this kind of word processor also has this
problem: you have to have a duplicate set of commands for the metadata
than for the data.

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, since basically we have in the
WYSIWIG window only the data (which can edited with usual emacs text
editing commands), and in the metadata window, only the metadata of the
current cell (or the current path of metadata nodes from the root of the
document down to the current cell, in the document structural
hierarchy).

+------------------------------------------------------------+
|    Chapter 1. Example
|
|       Section 1.1. Subtitle
|               
|          Sentence 1 of paragraph 1.  [S]entence 2 of
|          paragraph 1. 
+--U:**- Document.ewp ----(word)------------------------------+
| <document style="book">
|   <chapter style="nice">
|     <section style="standard">
|       <paragraph style="example" indent="0"
|                  leftmargin="0.5cm" rightmargin="1cm">
|         <character fontsize="+2">
+--U:**- Document.ewp/style.estyle ----(word-style)-----------+

With [S] representing the cursor on the letter S.


I don't see how usual emacs commands can be used to edit such a style
sheet path in the metadata window, since it's kind of a transveral
view.  Of course, when giving a command to change eg. the font of a
region, we could have text to edit with the regular emacs commands,
either in the minibuffer or in a box in the metadata window, but a M-x
replace-string RET would not be too useful on such a view.

Also, notice that a lot of interesting commands can be implemented, that
don't have a nice representation of the data they would work on.

For example, we could want a command that would replace the style of all
paragraph from "standard" to "personalized".  
M-x replace-paragraph-style RET standard RET personalized RET

This would reflect on the WYSIWIG window as an updated layout and
presentation.  And if we happen to have the cursor on a paragraph that
had the "standard" style, that would update the metadata window to now
show that the current paragraph style is now "personalized".  Buf if
that wasn't the case, we would have no feed back, or just a little feed
back in the WYSIWIG window, but often style changes are not drastic
therefore little noticeable.


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.


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).

And that the work needed to implement it will be offset by the sure win
that with such a set of commands, we will be able to further write other
commands in emacs lisp to manipulate emacs word processing document.
But then consider also that if the document is a structured tree, it can
be represented as a sexp (and only a validator would be needed to put
back such a document sexp modified by some user command), and similarly,
the style sheet can be represented as a sexp, so fundalementaly, no
additionnal function or commands are used to write emacs lisp code to
manipulate them.  We can still provide some utility to ease navigation
and modification of those trees while keeping their validity as document
and metadata trees.  A little like we could just take (buffer-substring)
and modify it in lisp before putting it back into the buffer, or we
could use (forward-word), (delete-region s e), etc, to edit the buffer
directly.  Only now we don't have just words and informal paragraph, but
we have a true document structure to support the styles, and we have a
metadata buffer with commands to edit the style sheet.  (map-styles
(lambda (style) (incf (style-fontsize style))) document) (add-style
"newstyle" '(:fontsize (pt 10) :left-margin (cm 3))) (replace-style
'paragraph "oldstyle" "newstyle")


Finally, let's note that a system like docbook can deal with different
kinds of document structures thru the DTD, and that the XSL are designed
to process specific kinds of DTD, so the structure of the style sheets
and the structure of the documents are not hard coded, but can be
parameterized with the equivalent of the DTD.  I'd move to support
docbook file formats, XML, XSL and DTD as external format for the emacs
word processing mode, as long as we convert them internally as sexps so
we may process them in a lispy way.

-- 
__Pascal Bourguignon__
http://www.informatimago.com/