Clones...

19 views
Skip to first unread message

Terry Brown

unread,
Dec 15, 2011, 5:28:19 PM12/15/11
to leo-e...@googlegroups.com
...are vicious deceitful little backstabbing...

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

HansBKK

unread,
Dec 15, 2011, 7:22:58 PM12/15/11
to leo-e...@googlegroups.com, terry_...@yahoo.com
On Friday, December 16, 2011 5:28:19 AM UTC+7, Terry wrote:

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-)

Edward K. Ream

unread,
Dec 15, 2011, 7:32:31 PM12/15/11
to leo-e...@googlegroups.com
On Thu, Dec 15, 2011 at 5:28 PM, Terry Brown <terry_...@yahoo.com> wrote:

> Never have liked clones, never will like clones ;-)

It wasn't clones that killed your work, it was refresh from disk.

EKR

Terry Brown

unread,
Dec 15, 2011, 10:11:22 PM12/15/11
to leo-e...@googlegroups.com
On Thu, 15 Dec 2011 19:32:31 -0500
"Edward K. Ream" <edre...@gmail.com> wrote:

> > 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

HansBKK

unread,
Dec 15, 2011, 11:47:28 PM12/15/11
to leo-e...@googlegroups.com, terry_...@yahoo.com
On Friday, December 16, 2011 7:22:58 AM UTC+7, HansBKK wrote:
better to practice on something expendable first. . 


 sorry thought this was the other Terry. . .

HansBKK

unread,
Dec 16, 2011, 4:19:34 AM12/16/11
to leo-e...@googlegroups.com, terry_...@yahoo.com
while I'm being egregious I'll also hijack the thread rather than starting a new one

I could have **sworn** I saw the option to clone multiple nodes at once **somewhere** or was I dreaming one of these middle-of-the-night sessions?

If clone-marked-nodes is the only way, is there a way to somehow "remember" all the currently marked nodes, unmark them do the copy and then mark them back? I guess I could use clones to help remember what parts of the outline I'm currently working in. Slowly my brain's getting Leonized 8-)

Edward K. Ream

unread,
Dec 16, 2011, 9:06:32 AM12/16/11
to leo-e...@googlegroups.com
On Thu, Dec 15, 2011 at 10:11 PM, Terry Brown <terry_...@yahoo.com> wrote:
>> 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.

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

Terry Brown

unread,
Dec 16, 2011, 10:29:29 AM12/16/11
to leo-e...@googlegroups.com
On Fri, 16 Dec 2011 09:06:32 -0500

"Edward K. Ream" <edre...@gmail.com> 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

Reply all
Reply to author
Forward
0 new messages