On Wed, Oct 5, 2011 at 8:16 AM, Edward K. Ream <[email protected]> wrote:
> *Important*: the clone-marked command is an easy special case: the > command creates a node to hold the clones first, *then* traverses the > entire outline. Thus, the positions of the marked nodes do *not* > change during the traversal (because the newly-cloned nodes become > children of the node that hold the clones). Ha. I think I've just discovered a safe way to move and delete marked nodes: do it iteratively. That is, each pass over the outline moves or deletes *one* marked node. True, this is much slower than a one-pass algorithm, but it has a chance of working :-) Indeed, in both the "move" and "delete" cases must deal with difficult special cases in which a marked node (or its clone!) is a descendant of a marked node. Hmm. This suggests a clever(?) strategy for the "move" case: *unmark* all nodes that are descendants of a marked node, but remember them (vnodes), and then mark the nodes *again* after the move is completed. This requires only a post-pass over the moved nodes, and so should be fast. Hmm again. There are two, not three, problems with this supposedly clever approach. First, the unmarking phase can be expensive itself. Second, to have any chance of working, moving nodes would have to be done in *reverse* outline order, so as to leave the positions of to-be-moved nodes unchanged. Third, and most importantly, it ignores an interesting design question. Suppose a marked node is a child of a marked node. What is to be done in this case? Do we move the child node first, thereby removing it from its ancestor, or do we move the parent node first, thereby "carrying" the descendant marked node with it? So upon further review, I think I'll simply use a multi-pass algorithm for moves. This is the simplest thing that could possibly work. Each move will carry all descendant moved nodes, thereby leaving structure of each moved *tree* unchanged. The alternative would be to "flatten" the moved nodes, which could be a big, unwanted, surprise. Anyway, the delete case almost certainly requires multiple passes. That's not so bad because deleting a node will, of course, delete all marked descendant nodes. A note about clones. The multi-pass *delete* algorithm will naturally handle clones properly. Any *move* algorithm will handle clones uniformly as well, because in the one-node world all clones are the *same* node. I'll add the move-marked and delete-marked commands today, while these issues are still fresh in my mind. BTW, I just checked that these commands do not already exist :-) And yes, these commands are worth the effort. Edward P.S. Getting undo to work correctly is going to be tricky. It would be too expensive to save before and after snapshots of the entire outline! The only way seems to be to have undo be the reverse of the move/delete command. That is, undo must *itself* be a multi-pass affair... EKR -- You received this message because you are subscribed to the Google Groups "leo-editor" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/leo-editor?hl=en.
