On Friday, August 16, 2019 at 4:39:06 PM UTC-5, btheado wrote: As Vitalije says" >> >> - Adding (or deleting) the last sibling will not change the position of >> any existing node. This *includes *adding/deleting the last top-level >> node. >> - If you can recast your algorithm in terms of vnodes, it will be >> impervious to changes in the outline. >> > > The way I read Vitalije's explanation, it sounded like the last child of a > subtree. But are you saying it is only the last node in the entire outline? >
No. See the emphasis above. Adding after *any* last sibling will leave all positions unchanged. Maybe I should start my journey on position enlightenment with c.redraw(). > If I see how positions are recomputed, maybe I will better understand the > behavior. > I wouldn't advise that. Instead, read << about the position class >>. If you want more detail, look at Position.__init__(). A position consists of *a stack of ancestor vnodes*, and *a child index*. If you move a node, both the stack and child index will change for descendant nodes. If you insert or delete a node, the child index of *sibling *nodes may change, and that will also affect the children of those siblings. But *no* positions will change if you only add/delete the *last* sibling. Clear? 2. Now that you have an @dates node, create your @date nodes as children of >> the @dates node. This will preserve all positions. >> > > Hmm, are you saying no matter where I create the @dates node all > previously create positions will still be valid? Even after making more > modifications like inserting @date nodes? > What I said was: 1. Creating the @dates nodes will change positions (unless you create the @date nodes as the last top-level node, or the last child of some other node). I *should *have said is that your script should call c.redraw to update the screen. 2. After you create the @dates node, inserting an @date node as the last child of the @dates node will leave all positions unchanged. *Important:* Usually scripts don't care much about changing positions. *Changing positions only bite you if you save positions.* Instead, it may be simpler to *recompute *positions of interest. Your script could scan for the @dates node (which will give you a valid position), and then the script could scan for the desired @date node in one of the children of the @dates node. Please feel free to ask more questions. This is a vital topic for anyone writing an interesting script. 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 view this discussion on the web visit https://groups.google.com/d/msgid/leo-editor/b7db3314-62e7-466d-a175-089c52cc107b%40googlegroups.com.
