On Thu, 19 Jun 2008 08:47:02 -0500 "Edward K. Ream" <[EMAIL PROTECTED]> wrote:
> This should work because p's position doesn't change when it's > children are deleted. The general case is even harder. One might > have to iterate repeatedly over the entire outline. Hmm, I can see where an outline with a couple of thousand nodes could be really unwieldy that way. My approach relies on making a list of nodes and reversing it so you know that you're not deleting the ground you're standing on, or will be standing on. I think you could write a generator based on a recursive iterator which would yield nodes in a sort of last child first order... but of course I'm not sure how it would interact with clones. I guess they shouldn't be a problem. Perhaps rather than a new iterator intended just for deleting, something like p.deleteChildren(cond) and p.deleteDescendents(cond) where cond is a callable taking one argument, a position, and returning True for False (delete or don't). So deleteChildren and deleteDescendents would be responsible for iterating in a safe way. Of course you want to take advantage of the efficiency of deleting a whole subtree first, rather than deleting a whole bunch of individual nodes in a subtree only to find that the whole tree also needs deleting. Perhaps there's no need to make a list and reverse it, seeing vnodes have back links (I think) it's cheap to iterate children first to last. I'll experiment and see what I come up with. Cheers -Terry --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "leo-editor" group. To post to this group, send email to leo-editor@googlegroups.com 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 -~----------~----~----~----~------~----~------~--~---
