I was editing a node in a @file tree. What I meant to do was copy /
paste first, then edit one copy. I forgot to copy / paste, and when I
realized what I'd done, I thought, to problem. Just dragged the edited
node out of the @file tree and then did rclick-'Refresh from file' on
the @file tree. Of course my dragged out of the tree node had the same
gnx as it's "ancestor" in the refreshed file, so they became clones and
my edits vanished.
Never have liked clones, never will like clones ;-)
Cheers -Terry
Never have liked clones, never will like clones ;-)
While reading your message an image from Count Zero popped into my mind:
> He watched a cheerful young mother slice pizza with a huge industrial waterknife in the kitchen corner of a spotless one-room.
It's a sharp instrument, handle with care, maybe better to practice on something expendable first. . .
I always teach that which I most need to learn 8-)
> Never have liked clones, never will like clones ;-)
It wasn't clones that killed your work, it was refresh from disk.
EKR
> > Never have liked clones, never will like clones ;-)
>
> It wasn't clones that killed your work, it was refresh from disk.
But I moved the modified node *outside* the @file node I refreshed. So
I think the result is surprising. It wasn't much work.
Cheers -Terry
better to practice on something expendable first. .
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?
Edward
> > 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