On Saturday, January 4, 2014 5:23:02 AM UTC-6, Edward K. Ream wrote:
> It's now time...[to use] the information in @auto-view nodes when reading
@auto nodes. This should be straightforward:
Recreating clone links is done. In fact, it was already done when I wrote
this post ;-)
> Recreating organizer nodes should be even easier in practice...
> [The following] theorem removes all confusion:
> The nodes that will become children of the newly-created organizer
node O
> will have the same parent [P] as O in the newly-imported @auto tree.
Rev 6516 completes the first draft of inserting organizer nodes. This
removes all risk associated with the @auto-view project. It now is a
demonstrable success.
There are details remaining. In retrospect, I would have thought that I
could have discovered the special cases I am about to discuss without
writing code, but doing the actual programming raises questions that I
never considered before.
In most cases, the newly-imported **organized** nodes (the children of the
to-be-created organizer node) will be the same as the old organized nodes.
This is important, because it means that @auto-view will usually "just
work". But we have to ask, what happens when previously-organized nodes
are deleted, or when P (the parent of the to-be-created organizer node O)
has **extra** children that were not previously organized?
The most general pattern is the following. Here, all nodes are in the
newly-imported outline.
- P (the parent of O, determined by the unl's for the *children* in the
corresponding @organizer node).
- leading extra node Extra 1
- organized node Child 1
- internal extra node Extra 2
- organized node Child 2
- trailing extra node Extra 3
As I write this, I see that there are two ways to insert the organizer node
so as to preserve the text of the @auto file:
1. minimize the nodes placed in O:
- P
- Extra 1
- O
- Child 1
- Extra 2
- Child 1
- Extra 3
2. Maximize the nodes placed in O:
- P
- O
- Extra 1
- Child 1
- Extra 2
- Child 1
- Extra 3
Maximizing the organized nodes is simpler, but minimizing the organized
nodes means that it is still possible to move leading comments from Child 1
into O's body. This suggests that we use the maximized scheme unless a)
one or more leading extra nodes exist and b) Child 1 contains leading
comments that could be moved to O, *provided* that the leading extra nodes
are *not* organized by O.
In short, we could use the maximized scheme, or the following scheme in the
special case just described:
- P
- Extra 1
- O
- Child 1
- Extra 2
- Child 1
- Extra 3 <---- This extra node *can* be organized.
The simplest thing that could possibly work is simply to use the maximized
scheme, and *not * move comments into O if Extra 1 exists. This preserves
the contents of the @auto file.
The user could, of course, move Extra 1 to a child of O later. The user
could also move leading comments from Child 1.b to O.b, but that would
change the contents of the @auto file. This could be a reasonable thing to
do, but it should never be done automagically.
To repeat, these complication will happen rarely. In any case, the
programming complication are slight, and are handled in a single place,
namely vc.create_organizer_nodes_helper.
> Perhaps only an hour or three remain to complete the project.
I plan to complete the code and integrate it into the @auto read/write code
today. As stated earlier, I plan to use @auto to generate leoViews.py
itself.
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.
