This is an ENB (Engineering Notebook) post.  Feel free to ignore.

This is a "thinking out loud" post, except that I've had the luxury of 
revising my remarks.

===== Terminology:

- Unless I indicate otherwise, when I discuss @view nodes I'll also be 
discussing @auto-view nodes.

- Let **V** denote an @view node or @auto-view node and let **D** be any 
descendant of V.

===== Overview

Conceptually, @view and @auto-view do different things, so they might have 
different formats.  However, it may turn out to be useful to use a common 
(or extensible) format.

@view and @auto-view nodes will (in essence) contain either:

A) A list of unl's in V.b (when V is packed) or

B) Descendant nodes corresponding to the unl's (when V is unpacked).

There are three main topics to discuss:

Part I.  Packing @auto and @auto-view nodes.
Part II. Unpacking @auto and @auto-view nodes.
Part III. Using the data in (packed?) @auto-view nodes.

===== Part I: Packing @auto and @auto-view nodes.

Packing means replacing all descendants D of V by unl's contained in the 
V.b, V's body text.

Question 1: what to do about any existing body text in the @view node?

This is a minor question and we can ignore it here.

Question 2: When packing, what unl do we use for each descendant D of V?

1. If D is a clone, we just replace D's *entire tree* by a clone that is 
*not* in V's tree.  If there is no such clone, we will use the solution in 
part 2.  If there are more than one clone of D not in V's tree, we would 
like to pick the best **representative clone** (representative, for short) 
of D.  Imo, the best representative would typically be the first (last?) 
clone found in any @<file> tree.

2. If D is not a clone (or if all clones of D appear in V's tree), then we 
must *create* a representative (uncloned) node as the "target" for the unl 
to be stored in V.b.

There are several possibilities, but the simplest thing that could possibly 
work is to put all representative nodes in the first @view-data node in the 
outline.  The code will create the @view-data node if it does not exist.

We probably want a node corresponding to V in the @view-data node.  Let's 
call this the **representative-root** node for V, RR for short.  The RR 
node might well have a timestamp.  In any case, all newly-created 
representative nodes will be children of the RR node for V.

In either case 1 or 2 above, the unl's stored in V.b must be the unl's to 
the representative nodes because packing an @view node will *delete* all 
descendants D of V.

In short, the answer to Question 2 is: the unl of each representative node.

===== Part II: Unpacking @auto and @auto-view nodes.

This is straightforward:  Using the unl's in V.B, we do the following:

1. Clone all the representative nodes, and move them to be children of V.

2. **Delete* RR and all its descendants, that is, all the representative 
nodes created when V was packed.

As a result, all nodes that were originally uncloned before V was packed 
will be uncloned after V is unpacked.

===== Part III. Using the data in (packed?) @auto-view nodes.

The details of this part remain murky at present.  However, it looks like 
we will want to associate a **kind** field with each unl.  This field will 
tell how the unl is to be interpreted.

For example, a to-be-inserted organizer node won't exist at all in the 
imported @auto tree.  It must be added.  We need kind == 'organizer' to 
indicate that a node should be created.

Other kinds of unl's may be useful in @auto-view nodes.

===== Summary

The three parts of this post correspond to the three fundamental 
view-related operations: packing @view nodes, unpacking @view nodes and 
rearranging @auto trees using @auto-view nodes. The first two operations 
are straightforward; the third may be complicated, but it has no affect 
whatever on any other part of Leo.

I am considering adding a new module:  leo.core.leoView.py.  This will be 
one of Leo's smallest modules, and one of it's most useful.

Your comments, please, Amigos.

Edward

-- 
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/groups/opt_out.

Reply via email to