RE: Emacs as word processor

[Drew Adams]

> Isn't it exactly just what we would want to avoid?

No.

As long as you have the possibility of properties (call them what you
like) being attached to individual characters irrespective of any
possible underlying structure, you want to make it easy to transfer
and copy sets of such properties.

Even in a structured application, the _possibility_ should be there.
This is the case, for example, in Framemaker.  You can use it for
both structured applications and for unstructured ones.

Even for use with a structured application, nothing _prevents_ you
from applying ad hoc formatting in Framemaker.  But of course users
of such apps themselves avoid doing that.  Neither I, nor any of my
colleagues, for example, have _ever_ used ad hoc formatting with
Framemaker for the documents we write, which are all structured (XML).

There's an overriding, simple reason for that.  Tools that create
different kinds of output (HTML, help, PDF, for different devices
etc.) work with the underlying structure (in a word, the XML data).
They ignore any ad hoc formatting.  So it does you no good to fiddle
with bold or italic here and there, instead of, say, wrapping an
element in a predefined Emphasis element that has a Role attribute
set to value CodeInlineBold (or whatever).

IOW, enforcement where and when appropriate, and according to strictly
defined schemas.  But nothing prevents you from ad hoc formatting, for
those cases where there is no structured app.

> Wouldn't we want to promote structured editing with style sheets, so
> that instead of pasting faces, you'd rather change the structure of the
> document, indicating <emphasis>, or <blockquote style="literary">
> and letting the word processor perform the style cascade and text
> rendering?

Yes, for a structured application.  That is typically enforced by an
XML Schema schema or a DTD or other validation tools, or at a minimum
by good practice.

Even then, the same UI principle applies.  In Framemaker I can copy
an XML element's attribute values and then paste them onto other
elements.  Depending on user preferences (strict or lax), doing that
to the wrong kind of element (one that does not have the same
attributes) will either be prevented or allowed.

This is a useful and common UI tool.  Whether you are copying a color
(a la eyedropper) or other text attributes, the same idea applies.
Kind of strange, IMO, that Emacs itself has not had such a simple
UI tool.

And yes, I do propose it as a start, for those of you who are
thinking of moving Emacs toward being able to do more WYSIWYG
editing. Copy faces, fonts, background color, whatever from here.
Paste over there. Piece of cake - quick, useful.  And that includes
pasting the absence of certain properties, in order to remove them
from the paste target.

Emacs, above all editors and environments, should not hardcode any
black-&-white behavior in this regard.  It should, on the one hand,
give users the tools to both (a) control editing rigorously, in a
structured way, and (b) on the other hand, allow users to fly by the
seat of their pants.

This should be a no brainer for Emacs.  Emacs was *the* counter
model, back in the 80s & 90s when some were promoting locked-in,
strict "structured editors" (often in Lisp, BTW, and often
implemented using Emacs).

The Emacs approach was to let you do pretty much anything, but to
also provide feedback and validation wrt the desired structure.
And if you wanted strict prevention, Emacs offered you that too.
Guess which model "won".  Au choix.  User control.

This is the Emacs way.  Anything less is limiting.