Re: enriched-mode and switching major modes.

[Oliver Scholz <alkibiades@gmx.de>]

Richard Stallman <rms@gnu.org> writes:

>     True, the current implementation allows future derivatives of
>     text-mode -- such as a major mode to write movie scripts -- to add
>     persistent colors to the text.
>
> It also allows existing simple variants of text mode, such as
> paragraph-indent-text-mode, to work with enriched mode.

But for things like this, enriched-mode-the-minor-mode should /not/
affect anything but encoding/decoding.  It should leave everything
else to the major mode.

>     But how often is this power used?
>
> Enriched mode is not used much, now.  Part of the reason is that we
> don't have code to save in the formats users really use, and part is
> that we have not implemented enough of the display formatting features
> that people want in a word processor.  This is an unfinished feature.

Indeed, I believe that in the long run Emacs' display engine should
support a real block model.

These two belong together, IMO.  It is very difficult to make Emacs
support formats that people really use in a WP-style way. Word
processors assign properties to paragraphs, including defaults for
character styles (like the font, the weight etc.); and they support
style sheets for that. It is very, very hairy to keep paragraphs,
their properties and their representation in an Emacs buffer in sync,
not to talk about style sheets.  In fact I do think that getting a WP
UI right in Emacs is currently impossible.  (However, I start to think
that some 60%-70% solution could be feasible. But I have not explored
that yet.)

Interesting coincidence, btw: I lately had a discussion via e-mail
with somebody who stumbled over a prototype RTF reader of mine on the
web.  He asked me to make enriched-mode support RTF as a format.  I told
him that this is not possible for the reasons above; even an
incomplete, possibly fragile, partial solution would require a major
mode.  It turned out that that person would be satisfied with something
which I call "bad RTF", that specifies font, font height, font weight
etc. everywhere explicitely; i.e. indeed something like text/enriched
but with a file format that is supported by more programs.  This,
however, could not really be called "word processing".  Personally, I
am not interested in such things and I think it is very wrong.

I do think that enriched-mode as a minor mode is a dead end.  If it
would restricted itself to just affecting visiting and saving, it
would be nice to have (I disagree with Alex Schröder here).  But this
is not how WP in Emacs could be like.  WP in Emacs should be based on
a major mode that handels every aspect of editing and representing
and that would support different file formats (RTF, HTML, TEI XML,
Docbook, maybe Texinfo) as a target.  And most importantly that major
mode would be responsible for providing an user interface to a block
model -- either a real one supported by the display engine, or a
fake one based on some half-obscure hackery.

> But does the lack of usage really make a difference here?
>
> 				       And
>     at what cost does this power come?
>
> I don't see the point here.  What do you think the cost is?
> At present, what we see a bug.  I admit that the bug is not
> trivial to fix, but I don't see that the "power" of enriched
> mode has a "cost" in some inherent sense.
>
>       Even if we wanted this power,
>     wouldn't it be better if such modes could just add some defun to a
>     hook or two that would automatically do the right thing: Automatically
>     encode and decode text properties upon saving and reading files.
>     Without all the other features of enriched mode which are rarely
>     useful in this case, such as the the treatment of newlines or the
>     keybindings.
>
> I am not really sure what feature you have in mind.
> It might be a useful feature, but it would not replace
> the existing feature of Enriched mode.

I think that Alex talks about writing new major modes that also use
text/enriched as a file format.  I think that this feature is already
there.  We have `after-insert-file-functions' and
`write-region-annotate-functions' (or `format-alist') and we have
`enriched-encode' and `enriched-decode'.


    Oliver
-- 
Oliver Scholz               25 Fructidor an 212 de la Révolution
Ostendstr. 61               Liberté, Egalité, Fraternité!
60314 Frankfurt a. M.