- Cutting and pasting multiple selected nodes, moving multiple selected nodes, etc, becomes trivial too with this approach. Attached Leo file does that to demonstrate what I mean, but requires an inmense amount of loops since I canot refer the absolute position on a tree.
Say we have a tree: A B C D E *Code required to cut/paste [D,E] just after [B] right now:* Get all items position A-1,B-2,C-3,D-4,E-5 for each item in the list [D-4,E-5] we have to: Loop through the tree. When we get to the position 4, we cut that node. Whenever the tree outcome changes, positions are updated, so we have to update also our position list. For every position bigger than 4, we substract one so we have now that [E-4] After finding it and cutting, we now loop again through the tree. When the loop index is 2 we paste the node. This position reference now must be updated to 3,since we pasted already in 2. Go to next position, repeat process. Calculations have to be made in case the paste position is after the nodes being cut (position 2 wont be stable) so each time we cut/paste a node, that position must also be updated. *Code required If positions were to also refer absolute position on the tree:* cut 4 paste in 2 cut 4 paste in 3 On Thursday, May 23, 2013 9:26:44 AM UTC+2, Fidel Pérez wrote: > > I have spent some time trying to make a function to loop through nodes > inserting childs, and after that I understand some of the reasons why > looping through nodes is so difficult. My conclusions are: > > - Since the position "p" of a node, right now, offers no more information > than the position on a tree which will disappear if the tree changes, we > might as well set the position value to be the actual numbered position > that node occupies in the tree. > This way we don't loose any information or functionality from the nodes > position reference, but instantly *win a reference*, since users will be > able to call nodes by their position on the tree, even if the tree changes > (When the tree changes we will obviously be calling the new node which > occupies that position). > - What I'm asking for is just a way to reference and call actual position > on the tree, by number,regardless of what has happened before or after or > which node is there, just go to the "nth" node in the tree, but *without > having to loop through all the tree for that*. > > This would make possible: > - Simple loops through the tree while editing it, since the user would > be able to "calculate" the absolute position of the nodes he wants edited > - Deletenodesinlist would instantly work through this approach (If our > list to delete is position [3,4,8], the function will delete nodes by > position [3,3,6], each time a node is deleted, all the numbers on the list > must be substracted 1) > > > Double loops are infernal right now, because you have to consider: > - When a node changes, all the positions will change > - If then there is a loop within the loop, after a node changed, there is > no way to keep reference in both loops (there is, we can make a list, but > then we would need another list in case of 3rd concatenated loop, another > in 4rth, etc etc) Not practical. > But again, I think this approach would also make those loops simpler. > > > > On Thursday, May 23, 2013 1:23:04 AM UTC+2, Edward K. Ream wrote: >> >> On Wed, May 22, 2013 at 11:09 AM, Terry Brown <[email protected]>wrote: >> >> > Just a thought - while it's fresh in your mind you could add a bit on >> building trees from scripts, p.insertAsLastChild etc. etc. >> >> It's on the list, but I don't think it has too high a priority. Getting >> clear about p.deletePositionsInList is much more important, imo. >> >> EKR >> > -- 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 post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/leo-editor?hl=en-US. For more options, visit https://groups.google.com/groups/opt_out.
