[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: enriched-mode and switching major modes.

From: Oliver Scholz
Subject: Re: enriched-mode and switching major modes.
Date: Sun, 19 Sep 2004 13:07:05 +0200
User-agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3.50 (windows-nt)

"Robert J. Chassell" <address@hidden> writes:

>    ... When working with a document in what you call the surface
>    expression, then it would be nice, if a command toggle would show
>    what you call the deep representation of a paragraph (a block box)
>    or a region.  Then you could make changes to that and issue the
>    command again to get the updated surface representation.
> If I understand you rightly, the idea here is that you look at one of
> the surface representations is a read-only display and maintain the
> same position in the read-write deep representation buffer.  You can
> either keep the two buffers visible at the same time or switch from
> one to the other.

Well, no. The idea is rather that you "fold" and "unfold" parts of a
buffer. Say, you edit the surface expression of a HTML document; then
you "unfold" the surface expression of a table and edit the HMTL code
(the deep representation) of that table directly. The rest of the
document stays in its surface expression. If you "fold" the table
again, you come to see the updated surface expression of the table.

`preview-latex' works similar (to a certain extent).  You edit the
LaTeX source (the deep representation), but `preview-latex' will
display certain (configurable) parts of it, such as tables, formulas
etc. in their surface expression /instead/ of the deep representation
/in the same buffer/.  If you want to edit the formula, you issue a
command to get the deep representation again.

My idea is to have /both/ the deep representation and the surface
expression read-write, as you say.  Again: I have not worked this out.
There may be pitfalls; I will spend thought on this only when
everything else is ready.  There are some fundamental differences to
editing LaTeX with preview-latex.  But it is too early too worry
about it.

There is btw. an interesting difference in our terminology. What you
call "the deep representation" is indeed what I call the "encoded
document file" and your "surface expression" is my "visual (aural)
appearance".  But it seems to me that the emphasis expressed in the
choice of words is different; not better or worse, just different.  In
the editing model that I pursue various deep representations (as well
as various surface expression) are just instances of an abstract
document.  In your editing model we have a particular deep
representation and a surface expression for that; a read-write surface
expression would just be another means to edit the deep
representation: Editing the deep representation is what one really
wants in this editing model.  Contrary to that, in the editing model I
prefer the deep representation is just a means to freeze the abstract
document on disc or to transfer it to another person[1].  I think that
some people would prefer your view, and so it seems a good idea to me
to spend some thought---when the time is ripe---on how both could be
made compatible, so that people can get the best of both worlds at
their choice.  This is another area where Emacs could excel compared
to traditional word processors.

> This sounds good.  Moreover, it is less complex than writing a program
> to edit a sufficiently complex surface expression.

Hey!  I am the guy who desperately wants to edit really complex
surface expressions. :-)

> Generally, I would expect you to look at at least two different
> surface expressions at the same time, such as Info and DVI.  This way
> you could avoid accidentally focusing too much on just one output
> format.  With the deep representation, this means three visible
> windows.  You might set things up so that by default a frame is laid
> out with three windows above each other.

This is quite different.  David Kastrup has written a paper discussing
the merits of various preview models, which could be of interest here.
I don't recall the URL, though.



[1] There is an interesting analogy to what Emacs provides at the
character level.  I found out that my terminology corresponds to the
structure of Emacs' handling of character encoding.  But there is not
enough space left on this e-mail to prove that statement.

Oliver Scholz               Jour de la Raison de l'Année 212 de la Révolution
Ostendstr. 61               Liberté, Egalité, Fraternité!
60314 Frankfurt a. M.       

reply via email to

[Prev in Thread] Current Thread [Next in Thread]