On Tue, Apr 22, 2008 at 10:26 AM, Terry Brown <[EMAIL PROTECTED]> wrote:
> > On Tue, 22 Apr 2008 10:11:30 -0500 > "Edward K. Ream" <[EMAIL PROTECTED]> wrote: > > > Apparently our emails crossed on the net. Your statements are > > exactly as I understand the situation, and exactly as I intend the > > situation to be. > > Criss-cross emails, like criss-cross merges, only less troublesome :) > > > The stack is "fully populated" in the sax-graph world, which means > > that the entire set of parents at a position is always easily > > accessible. However, this is really an internal implementation > > detail. > > Given that you can arrive at the same node by different paths, I think a > fully populated stack gives plugins a valuable tool for determining context, > so I don't think it's just an internal implementation detail. Hmm. p.parent, p.directParents, p.parents_iter, p.self_and_parents_iter and p.isAncestorOf are the recommended way of determining context. They should usually suffice. Plugins that want to remember positions in uA's must use p.archivedPosition. So I still think that the stack is better thought of as a black box. BTW, recent work shows that the graph world is just a bit more fragile than the old world. This is a direct consequence of using positions to determine virtual sibling links. Indeed, sibling links do not (and can not) exist in any graph world, so the fundamental code that manipulates positions and nodes must take special care never to use a position after the outline has changed. This principle applies to scripts and plugins as well as to Leo's core. Code like the following is asking for trouble: p = c.currentPosition() << insert, delete, clone, cut or paste nodes >> c.setCurrentPosition(p) This kind of code is actually rare: usually the code that alters the outline sets the current position as a side effect. As another example, calling p.unlink redundantly is more dangerous now. Previously, the code was a do-nothing if p.v had already been unlinked. Now the code must take more care not to delete the wrong node. I'll put some new checks in soon, but there are ambiguous cases involving clones that probably can't be fully fool-proofed. The only solution is to ensure that p.unlink is no longer called redundantly before methods like p.moveAfter, p.moveToFirstChild, etc. I've removed such redundant calls from the sax-graph core. 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 -~----------~----~----~----~------~----~------~--~---
