Re: enriched-mode and switching major modes.

[Oliver Scholz]

"Eli Zaretskii" <address@hidden> writes:

>> From: Oliver Scholz <address@hidden>
>> Date: Wed, 22 Sep 2004 12:01:27 +0200
>> Cc: address@hidden, address@hidden, address@hidden, address@hidden
>> 
>> For simplicity, I focus on elements and character data here and talk
>> about them as "nodes" in a tree; thus we have "element nodes" and
>> "text nodes".  An XHTML fragment like
>> 
>> <h1>Some <em>meaningless</em> text</h1>
>> 
>> Would be regarded as a `h1' element node which has three children: a
>> text node "Some ", an element node `em' (which has itself a text node
>> as its single child) an another text node " text".
>
> I'm not sure I understand why you want a tree-like representation for
> that.  Is it only so you can find what you call ``the immeditate
> parent of the current node''?

Since I don't want to render a given XML document /only/, but to make
it /editable/ also, I have to preserve the structure/the information
contained in the original document.

There is no requirement that the data structure is a tree in a strict
sense immediately (in fact, the XML information set spec explicitely
states that this is not required).  But it must be possible to map a
tree into that data structure and to map that data structure into a
tree; so that the original tree is regenerated after doing both.  The
data structure that I presented as #2 is actually not a tree in itself
(no link to the parents and children on a node); but I can compute
tree-like relations from it.

> Perhaps it would be better to step back for a moment and describe the
> operations you will need to perform on fragments of the document text,
> and only _then_ think about an appropriate data structure. 

I am not sure that I understand what you mean here.  First and
foremost I want that data structure to preserve the information
contained in a specific file format (here: XML).  

Then, to implement CSS I need an interface to whatever data structure
I use that presents it as a tree.

> The fact that the XML people came up with a tree does not mean you
> should follow suit; there might be other appropriate data
> structures.  For example, why not a list (which is a native data
> structure in ELisp)?

Lists are fine in general:

'(h1 "some " (em "meaningless") " text")

SXML uses lists in a similar way to represent the XML information
set. <URL: http://okmij.org/ftp/Scheme/SXML.html>
Emacs Lisp XML parsers that generate similar lists include:
nxml-parse.el, xml.el and xml-parse.el.

That nodes have no reference to their parent in a non-circular list is
not much of a problem, because for a given node, I can find its parent
by scanning the list.  So the information is preserved.

The solution I presented as #1 could be implemented this way by
representing text nodes as a unique Lisp object that is put into a
`text-node' text property.  In fact, I intended for a long time to do
it exactly like this (using SXML).  But I distrust the robustness of
this solution.  (After some thought I also realized that using SXML is
a bit pointless, but that is another issue, probably not relevant
here.)

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