Re: enriched-mode and switching major modes.

[Oliver Scholz]

Alex Schroeder <address@hidden> writes:

> Oliver Scholz <address@hidden> writes:
>
>> But I have to start somewhere.  The tree interface to this kind of
>> documents is well known and tested in practice.  Almost every
>> specification talks about trees.  So if there are no principal
>> objections to improving Emacs to better work with trees-in-a-buffer in
>> the long run, I think that I fare better by assuming a tree-interface.
>
> One of the problems you described was keeping a tree and the buffer in
> sync.  If you had a way of regenerating the tree based on the text in
> the buffer when saving a file, would that not be enough?

Yes, it could be enough.  It just makes implementing everything else
much more difficult and non-intuitive.  Nearly every specification
that could be directly or indirectly important (CSS, XPath, XSL even,
XForms, maybe various schemas, maybe others) describes the information
set as a tree.  When implementing I would have to translate that to
the custom data structure for reasons of efficiency.  And first I
would have to find that data structure---maybe #2 is it, maybe not.
(True, it is wrong to worry about efficiency prematurely, but since
this application must respond to user actions interactively, it must
not make efficiency impossible by design.)

Thus, if the outcome of this thread is that using a tree interface is
o.k., because later Emacs can be enhanced to deal with
trees-in-a-buffer in a way that avoids the syncing problem, then this
is like christmas for me.  (It is not important then, whether the
actual implementation hidden behind the interface relies on improved
overlays, extents or even an entirely new data structure.)

    Oliver
-- 
Oliver Scholz               3 Vendémiaire an 213 de la Révolution
Ostendstr. 61               Liberté, Egalité, Fraternité!
60314 Frankfurt a. M.