On Thu, Oct 6, 2011 at 7:03 AM, mdb <[email protected]> wrote: > I do want to be sure I understand the new code > -- moves forward in tree
Correct. Your idea of moving backwards in the tree was a crucial idea that got thrown away after it transformed our thinking. The point is that p.positionAfterDeletedTree is just as safe as traversing backwards. > -- relies on 2 new functions > p.positionAfterDeletedTree() > u.afterDeleteMarkedNodes() Yes. positionAfterDeletedTree is the Aha. u.afterDeleteMarkedNodes is the standard kind of undo helper that interfaces with Leo's too-complex undo system. > If I mark a cloned node, the other cloned nodes are also marked and hence > deleted. Correct. A problem. > Maybe a concept of local marking or selection is needed. Nothing that is associated with a node could possibly work, because all clones of a node are in fact exactly the same node. That's what we mean when we say that Leo has moved to "the one-node world". The alternative is to make copies of *positions*. Here, a backward traversal would seem to be essential. Also, the node containing all the to-be-moved-or-copied nodes *must* be inserted at the root position, to guarantee that its position never changes during the (backward) traversal. > Also completely separate issue: I think delete in context_menu has > unexpected undo / redo effects. Redo after Undo often fails, but you > can Undo again. Must be related to different undoable code when > deleting nodes through context_menu verses Outline menu Please file an official bug report. https://bugs.launchpad.net/leo-editor/+bugs Thanks. Edward -- 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.
