Re: [Texmacs-dev] DOM and TeXmacs roadmap

[David Allouche]

On Tue, Jul 29, 2003 at 06:48:52PM +0200, Immanuel Normann wrote:
> David Allouche wrote:
> 
> >DOM level 1:
> >
> > Structure navigation: can be implemented quite easily using a
> >   SXML-like approach to the STM (Scheme TeXmacs) document
> >   representation. All STM documents can trivially be considered SXML
> >   documents.
> > 
> >
> The SXML project has attrackted me since while. Now I am interested 
> about your experience with SXML in TeXmacs. Is there some experimental 
> code around where manipulate the STM with some SXSLT for instance?

Sorry for the late reply.

I do not have this. Actually, when you really look at it, your realize
that SXSLT (that is, the PREPOSTORDER function) is not XSLT at all.
TeXmacs uses its own specific dispatching functions to perform tree
transformations.

> 
> > Document manipulation/content manipulation: can be implemented in
> >   the current framework, the current work on converters and generic
> >   structural operators makes it a active field at the moment. One
> >   important (and currently unsolved) problem is the duality between
> >   the relatively static (but easy to use) STM document manipulation
> >   and the more complex (but more dynamic) manipulation of live data
> >   in editors. I will have a look at the DOM spec to help me in my
> >   quest for enlightenment.
> >
> What is your precise notion of "dynamic manipulation of life data"?

Tree data in editors is "live" because operating in a editor helps:

  -- reducing the retypesetting time;

  -- preserving the cursor and markers positions.

Good use of "editor tranformations" applies only minimal changes on
the document tree using a number of fundamental mutators (join, split,
join-unary, rem-unary, insert, remove, assign).

On the other hand, when working with STM data, one only uses TM-ASSIGN
which destroys all recorded positions and requires a complete
retypesetting for the assigned subtree (which is often the whole
document).


> >DOM level 2:
> >
> >
> > Range model: TeXmacs has a "marker" facility which allows for
> >   position markers which are robust when the document tree is
> >   modified. So this part of DOM might be partly implemented. The
> >   "range of text rather than subtree of nodes" concept is not
> >   planned to be a core feature but it might be implemented as a high
> >   level library.
> > 
> >
> How do I get and set those markers in Scheme?

You use the following primitives defined in build-glue-editor.scm (in
the source tree).

  (tm-position-new) -> int
  (tm-position-delete int) -> void
  (tm-position-set int path) -> void
  (tm-position-get int) -> path

TM-POSITION-NEW creates a new POSITION object and return its unique ID.
A newly created POSITION object has and undeterminated value.

TM-POSITION-SET associates a the POSITION with the given ID to a path
in the document tree. When the document is modified using INS_UNARY,
REM_UNARY, INSERT, REMOVE, JOIN or SPLIT, positions' pathes are
updated in the same way as the caret. When a POSITION's path points to
a tree being ASSIGNED to... well... I do not know what happens.

TM-POSITION-GET gives the PATH associated to the POSITION whose ID is
given.

When you are finished working with a POSITION, you should destroy it
using TM-POSITION-DELETE so TeXmacs no longer spend time updating it.

Ideally POSITIONs should be first class objects and TM-POSITION-DELETE
should be automatically invoked by the garbage collector. This
probably will happen one day, at which point TM-POSITION-DELETE will
be defined as NO-OP for backward compatibility.

So please do not rely on POSITION IDs being integers, consider them
opaque objects.

-- 
                                                            -- ddaa