On Fri, 16 Dec 2011 09:06:32 -0500 "Edward K. Ream" <[email protected]> wrote:
> > But I moved the modified node *outside* the @file node I refreshed. So > > I think the result is surprising. It wasn't much work. > > A recent change may be relevant here. To fix a clone bug, rev 4872 > saves and restores c.fileCommands.gnxDict when pasting an outline. > > Anyway, copying and pasting a tree (*not* paste-as-clone) should > ensure that all the gnx's in the pasted tree are distinct from all > previous gnx's. If that is not so it is a major bug. In particular, > after pasting a tree it should be impossible to change that tree using > refresh from disk. Are you saying that it is possible? I didn't copy paste, I just dragged the modified node outside (above) the @file node. I see what happened. The issue is how to respond to loading a derived file and finding one of its nodes has a gnx already present in the outline. Given that there's no guarantee their content is the same, making them clones is potentially destructive, but more than that it's surprising. Let's try this - create new outline - create @file node with three child nodes - save outline, creating derived file on disc - move one node out of @file to top level - delete @file node from outline - save - modify node dragged out of @file node - load @file node into outline again hmm, the modified node did not become a clone of its 'ancestor', I though it might. Maybe refresh from disk takes a slightly different path than regular load. 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 [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.
