Re: enriched-mode and switching major modes.

["Eli Zaretskii" <eliz@gnu.org>]

> From: Oliver Scholz <alkibiades@gmx.de>
> Date: Thu, 16 Sep 2004 19:04:53 +0200
> Cc: boris@gnu.org, emacs-devel@gnu.org, alex@emacswiki.org
> 
> 2) the data structure used to represent that abstract document
>    internally

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.

> > The idea of Emacs is that the appearance is represented by text in the
> > buffer.  We designed text properties so that the text in th ebuffer
> > could be something more than a sequence of characters.
> >
> > Any extensions have to preserve this principle, or we will lose
> > the benefits of Emacs.
> 
> I obviously disagree, since I argued for an enhancement that goes
> well beyond this principle.  I fail too see at all how we would lose
> the benefits of Emacs this way.

I think Richard refers to the fact that your suggestions are so
incompatible with the design principles and the current workings of
the Emacs display engine that implementing them would mean working
against the Emacs design.

The solutions you propose for the problems raised by Richard (how to
deal with line breaks and indentation from Lisp) already show a
potential to require changes in too many parts of Emacs, including in
lots of Lisp code.  That is already an evidence that trying to display
too many things that are not in the buffer is a path we should avoid.

> > 3. How to represent indentation.  If the indentation appears only
> > in redisplay, Lisp code that looks at the text will think it is not
> > indented at all.
> 
> I actually regard this as a feature.  In WP documents the left margin
> has no more significance than the right margin, which is not currently
> implemented by adding space characters, either.

That's not what Richard was thinking and talking about, AFAIU.  One
example of where the indentation _does_ matter, even in a word
processor, is when the mouse pointer hovers above a displayed portion
of text: you need to be able to compute the buffer character position
which is displayed below the mouse pointer.  If the code that computes
that doesn't know about indentation, you will never get that right.
This breaks the mouse-highlight feature and the tooltips, for
starters.

> > This model fails to address those problems.  It would work as a way
> > of grafting a separate word processing facility into Emacs, but it
> > would not integrate well with the existing Emacs Lisp world.
> 
> I don't understand why you say that.  And I don't know which parts of
> the existing Lisp world you mean.

The parts that do their work by walking the buffer text and making
decisions on how that text is displayed.

> > However, later you talk about an implementation more like what I have
> > in mind, where the boxes and lists would be rendered by changing the
> > buffer text; therefore, the buffer text would show what's really
> > there.
> 
> Erm, what does the concept of "what's really there" in that context
> mean?

What's really there in the buffer.