Re: Emacs as word processor

[Stephen J. Turnbull]

Eli Zaretskii writes:
 > > From: Thien-Thi Nguyen <address@hidden>

Listen to Master Thi.  He is wise and appreciates the Zen of
Motorcycle Maintenance, and well groks the higher-order Quality.

 > > If "faces" (the concept) were to include these extra-character
 > > features, then their composition would be greatly complicated.
 > 
 > That ship sailed a long time ago: we already have 'line-spacing' text
 > property.

Which demonstrates why it is unfortunate that text properties are the
primary interface in Emacs.  They're too easy to use for things that
conceptually attach to text units larger than single characters, but
they have no clue about such units -- it's entirely up to the user to
DTRT.

 > Indentation and justification are no different.

Ah, but they *are* different, at least potentially.  Default line
spacing can be implemented by changing the depth of the character box,
uniformly without respect to the identity of the character, for all
characters covered by that face.  (I suspect that's how this works in
Emacs; XEmacs doesn't have the feature AFAIK.)  Indentation and
justification are much more complex: they depend on the semantics of
the text, possibly including the particular characters.  For example,
in Japanese typography, punctuation and certain ligatures are allowed
to protrude on the right margin in fully justified text.  And line
spacing *also* should have a variant that applies to larger units of
text.  (Note that TeX implements both, and Knuth points out in the
TeXbook that use of extended depth to implement "poor man's
double-spacing" is ugly and hardly readable.  But it's possible in
principle.)

 > [Structured styles] is the source of all evil in Office.  The
 > result is a terrible mess where the user ends up having no control
 > on what is going on in her document (except for very short
 > documents).  No, thanks.

No, that's not the problem.  The problem is that *Office separates
editing of styles from editing of the document, making style editing
the province of experts.  And *Office does a rather sucky job on
things like indentation and mark formatting of bullet lists and
enumerations (at least in Japanese documents).

But it doesn't have to be that way.  A simple implementation of Drew's
"structured document WYSIWYG" would be as with many calendar programs,
which ask if a repeating appointment should be changed throughout, or
only on this date.  Concretely, if you edit a section heading's style
(eg, changing Helvetica to Times New Roman), Emacs could issue a query
asking

    Do you want to edit just this instance?
    Change font family to /Times New Roman/ in section headings at:
    [All levels] [This level] [This heading only] [Cancel]
    [ ] Review exceptional headings at affected levels

If you check the "Review" button, it would pop up a buffer listing all
exceptional headers at affected levels (ie, those with different font
families from the global style), with check boxes to revert them to
the global style, with execute options [Revert all] [Revert selected]
[Revert none].  (Not [Cancel] for the last, because that could be
construed to apply to the whole heading edit operation.)

You don't have to like the details of the workflow I just outlined,
although I suspect that applied to header, footer, and section
headings it would be quite acceptable.  In the body we would probably
want a separate command (or perhaps use universal prefix?) to access
styles rather than local formatting.  (I'm not actually sure of that.)

This doesn't address the issues of creating styles (ie, defining
"section heading" as a unit for style editing, and the associated UI
elements), and the balance between flexible control at the level of
individual words and providing structured styles is going to require a
lot of attention to detail.  But I think such an approach provides
both simplicity and sufficient control for "simple WYSIWYG document
processing".