Re: enriched-mode and switching major modes.

[Eli Zaretskii]

> Cc: address@hidden,  address@hidden,  address@hidden
> From: Oliver Scholz <address@hidden>
> Date: Fri, 17 Sep 2004 16:34:01 +0200
> 
> > Note that in Emacs, that data structure is the buffer text (with
> > associated text properties and any Lisp code that those properties
> > evaluate).  This is very important thing to understand: there are no
> > data structures built by Emacs from the text it reads except what it
> > puts into the buffer.
> 
> Fine. In that case Emacs can not become a word processor. Or maybe it
> already is: the first "word processor" which supports only the file
> formats text/plain and text/enriched.
> 
> That means I can stop thinking about implementing word processor
> functionality for Emacs right now and go back to use it just as a
> programmer's editor.  It is not the application then, that I thought
> it would become.
> 
> Sorry, for having been a nuisance, then.

That's a very far cry from what I intended.  I didn't mean to say that
the idea of having more word-processing features in Emacs was futile,
much less that your messages were a nuisance.  All I was saying was
that Emacs design has some basic assumptions which are better left
alone.

It is possible that what I wrote was misunderstood to mean that
there's nothing in the buffer but plain text.  Others in this thread
pointed out something that I assumed was known and obvious: that text
properties are also part of buffer text, and that they can be used to
hold the additional meta-information required for word-processing
features.

FWIW, I think there _is_ a way to add sophisticated word-processing
capabilities to Emacs without breaking the basic Emacs design
assumptions.  One good idea was already suggested in this thread: when
Emacs decodes a file which has embedded information about the text
layout, it should convert that information into a combination of
characters and text properties, such that Lisp programs and C code
that look at the buffer text could extract the layout information from
that text alone.  In other words, convert indentation to the
appropriate amount of whitespace, add newlines where line-wraps are
required (and put some text properties on those added characters to be
able to treat them specially, e.g. at save-file time), add text
properties for paragraph-level style information, etc.

If you think that this approach will not work, can you tell why?