Re: On the Semantics of Copying Clones

[Thomas Passin]

Aren't the marks used in goto commands, like goto-next-marked?  I use them 
all the time.

On Wednesday, May 27, 2020 at 8:26:26 AM UTC-4, Edward K. Ream wrote:
>
>
>
> On Wed, May 27, 2020 at 6:34 AM vitalije > 
> wrote:
>
>> Mark bits are really relevant only when copying node. After the copy has 
>> been made, the information which nodes were marked is on the clipboard and 
>> therefore is available to the paste-retaining-marked command. Even after 
>> unmark-all command as long as the clipboard is not changed, 
>> paste-retaining-marked will do its job correctly.
>>
>> Of course there can be assigned another flag for this purpose but I've 
>> never used marks for anything else but for clone-marked-nodes command. 
>> Perhaps there is something else that this flag can be used for but I am not 
>> aware of it. If its main purpose is to mark nodes user wish to clone in the 
>> future, then it seems to me a fair use case for this command. 
>>
>
> I agree.
>
> 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 leo-editor+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/6e1c5bb5-6585-42c2-a155-1369b8ddbd37%40googlegroups.com.

Re: On the Semantics of Copying Clones

[Seth Johnson]

On 5/27/20, Seth Johnson  wrote:
> On 5/27/20, vitalije  wrote:
>>
>>> > Indeed we can look at vnodes and we'll see that each node found on the
>>> > clipboard has a corresponding node with the exactly the same gnx among
>>> > the known vnodes (providing that we copied from the same outline and
>>> > that
>>> > outline has not been modified since). If we use this information to
>>> > decide whether node should be cloned or not then each node will be
>>> > cloned
>>> > and we would have just what paste-retaining-clones does.
>>>
>>> Right!  And you would be able to identify "internal sets" that match
>>> and easily template-as-encapsulated with new vnodes, if the user
>>> chooses to do the encapsulated template mode.
>>
>> I am sorry but it seems that you misunderstand my previous message. I was
>> explaining why it would be useless to look in vnodes even though we can
>> do
>> that no usable information will be retrieved from such lookup. However
>> your
>> other idea (checking if the node is single or not in the whole outline)
>> might work.
>
>
> I think I got you, but tried to add a little more on.  Now I'm not
> sure what you mean by single or not in the whole outline.  You mean
> the suboutline being pasted as template?  Or the entire Leo outline
> you're working within and making templates within?
>
> I don't get why you can't look at the vnodes for the clones in the
> suboutline (let's call it the t-outline, for the suboutline tree that
> you've grabbed in the clipboard to make a template from), and identify
> all those in the t-outline that associate with identical vnodes.  Each
> such set of nodes within the t-outline that point to the same vnode,
> get a new vnode and all of those clones get pasted as pointing at that
> new vnode instead.  Thereby you've made the template's clones "local."
>
> Just go through the t-outline and make a list of gnxs and their
> current vnodes.  When pasting, make new clone nodes pointing a new
> vnode for all of those that have the same/identical vnodes.  Any
> clone-nodes in the t-outline that are solitary, with their own unique
> vnode, just get pasted as plain nodes.
>
> This would be different from paste-retaining-clones.  (I guess
> paste-retaining-clones already does what I call template-as-global,
> right?)

I'm not using the vnodes to decide what gets cloned or not; I'm using
it to decide which clones in the t-outline are a set (because they
point at the same vnode), and thus they get a new vnode instead of the
one they had.  You use the vnodes to identify these internal sets of
clones, so you can treat them as "local clones" by giving them a new
common vnode inside the template.



> Seth
>
>> Vitalije
>>
>> --
>> 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 leo-editor+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/leo-editor/fb5f0a3c-ecf7-464c-9b68-fc311e8a0c31%40googlegroups.com.
>>
>

-- 
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 leo-editor+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/CAJkfFBxpgU5ER6QTvCZy6xcdBzbtS3utY8B_Uum9M%2BF4p4CUzQ%40mail.gmail.com.

Re: On the Semantics of Copying Clones

[Seth Johnson]

On 5/27/20, vitalije  wrote:
>
>> > Indeed we can look at vnodes and we'll see that each node found on the
>> > clipboard has a corresponding node with the exactly the same gnx among
>> > the known vnodes (providing that we copied from the same outline and that
>> > outline has not been modified since). If we use this information to
>> > decide whether node should be cloned or not then each node will be cloned
>> > and we would have just what paste-retaining-clones does.
>>
>> Right!  And you would be able to identify "internal sets" that match
>> and easily template-as-encapsulated with new vnodes, if the user
>> chooses to do the encapsulated template mode.
>
> I am sorry but it seems that you misunderstand my previous message. I was
> explaining why it would be useless to look in vnodes even though we can do
> that no usable information will be retrieved from such lookup. However your
> other idea (checking if the node is single or not in the whole outline)
> might work.


I think I got you, but tried to add a little more on.  Now I'm not
sure what you mean by single or not in the whole outline.  You mean
the suboutline being pasted as template?  Or the entire Leo outline
you're working within and making templates within?

I don't get why you can't look at the vnodes for the clones in the
suboutline (let's call it the t-outline, for the suboutline tree that
you've grabbed in the clipboard to make a template from), and identify
all those in the t-outline that associate with identical vnodes.  Each
such set of nodes within the t-outline that point to the same vnode,
get a new vnode and all of those clones get pasted as pointing at that
new vnode instead.  Thereby you've made the template's clones "local."

Just go through the t-outline and make a list of gnxs and their
current vnodes.  When pasting, make new clone nodes pointing a new
vnode for all of those that have the same/identical vnodes.  Any
clone-nodes in the t-outline that are solitary, with their own unique
vnode, just get pasted as plain nodes.

This would be different from paste-retaining-clones.  (I guess
paste-retaining-clones already does what I call template-as-global,
right?)


Seth

> Vitalije
>
> --
> 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 leo-editor+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/leo-editor/fb5f0a3c-ecf7-464c-9b68-fc311e8a0c31%40googlegroups.com.
>

-- 
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 leo-editor+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/CAJkfFByJTzcE0dY8Fmr2O%2BLLnwSssoZzvG7da2%3Ddnt68cpf3Tw%40mail.gmail.com.

Re: On the Semantics of Copying Clones

[vitalije]

> > Indeed we can look at vnodes and we'll see that each node found on the 
> > clipboard has a corresponding node with the exactly the same gnx among 
> the 
> > known vnodes (providing that we copied from the same outline and that 
> > outline has not been modified since). If we use this information to 
> decide 
> > whether node should be cloned or not then each node will be cloned and 
> we 
> > would have just what paste-retaining-clones does. 
>
>
> Right!  And you would be able to identify "internal sets" that match 
> and easily template-as-encapsulated with new vnodes, if the user 
> chooses to do the encapsulated template mode. 
>
>

I am sorry but it seems that you misunderstand my previous message. I was 
explaining why it would be useless to look in vnodes even though we can do 
that no usable information will be retrieved from such lookup. However your 
other idea (checking if the node is single or not in the whole outline) 
might work.
Vitalije

-- 
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 leo-editor+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/fb5f0a3c-ecf7-464c-9b68-fc311e8a0c31%40googlegroups.com.

Re: On the Semantics of Copying Clones

[vitalije]

On Wednesday, May 27, 2020 at 2:37:57 PM UTC+2, Differance wrote:
>
> On 5/27/20, Seth Johnson > wrote: 
>
> The simple approach is if there are more than one of the same 
> vnode in the outline you've grabbed to paste-as-template, those all 
> get a new vnode and become clone-nodes pointing to that instead.  If 
> they are loners within the outline you've grabbed, make them plain, 
> non-clone nodes.  
>

Hmm, this might work. I'm not 100% sure about that, but it just might work. 
Here is a function that would say if a node appears more than once in the 
outline or not. 

def is_unique(v):
while v is not c.hiddenRootNode:
if len(v.parents) == 1:
v = v.parents[0]
else:
return False
return True

Vitalije

-- 
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 leo-editor+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/02de850b-f2d1-4a60-ba74-0f4f5042ab66%40googlegroups.com.

Re: On the Semantics of Copying Clones

[Seth Johnson]

On 5/27/20, vitalije  wrote:
>
>
> On Wednesday, May 27, 2020 at 2:09:37 PM UTC+2, Differance wrote:
>>
>> On 5/27/20, vitalije > wrote:
>> > @Differance
>>
>> Speaking roughly, I think regardless of the structure of the tree
>> you've put in the clipboard, you can identify some that are clones of
>> each other within the tree -- can't you look at vnodes to see the
>> clones?
>
> Indeed we can look at vnodes and we'll see that each node found on the
> clipboard has a corresponding node with the exactly the same gnx among the
> known vnodes (providing that we copied from the same outline and that
> outline has not been modified since). If we use this information to decide
> whether node should be cloned or not then each node will be cloned and we
> would have just what paste-retaining-clones does.


Right!  And you would be able to identify "internal sets" that match
and easily template-as-encapsulated with new vnodes, if the user
chooses to do the encapsulated template mode.

Plus, no need to go through marking things, even thinking hard about
what you want "encapsulated" int he template and what you don't.  You
just think about whether in general what you want is for this template
to be independent of other clones in the outline.  You might generally
prefer the clones be global.  You could start with either type of
template, encapsulated or global, and manually edit them wherever you
want the other kind of clone.

Marking things to be local might be a more take-charge mode, with a
special "tailored-template" command.  My scheme seems easier and
simpler, no?   :-)


> Vitalije
>
> --
> 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 leo-editor+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/leo-editor/8336416d-1565-405c-928a-1a86afb09515%40googlegroups.com.
>

-- 
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 leo-editor+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/CAJkfFBz3A1FJrQRgChyhrW9458Jv9BmFsO-qweptfTWNK8NRhg%40mail.gmail.com.

Re: On the Semantics of Copying Clones

[vitalije]

On Wednesday, May 27, 2020 at 2:09:37 PM UTC+2, Differance wrote:
>
> On 5/27/20, vitalije > wrote: 
> > @Differance 
>
> Speaking roughly, I think regardless of the structure of the tree 
> you've put in the clipboard, you can identify some that are clones of 
> each other within the tree -- can't you look at vnodes to see the 
> clones?  
>

Indeed we can look at vnodes and we'll see that each node found on the 
clipboard has a corresponding node with the exactly the same gnx among the 
known vnodes (providing that we copied from the same outline and that 
outline has not been modified since). If we use this information to decide 
whether node should be cloned or not then each node will be cloned and we 
would have just what paste-retaining-clones does. 

Vitalije

-- 
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 leo-editor+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/8336416d-1565-405c-928a-1a86afb09515%40googlegroups.com.

Re: On the Semantics of Copying Clones

[Seth Johnson]

On 5/27/20, Seth Johnson  wrote:
> On 5/27/20, vitalije  wrote:
>> @Differance
>>
>> On Wednesday, May 27, 2020 at 11:56:57 AM UTC+2, Differance wrote:
>>>
>>> Couldn't a paste-as-template just traverse the tree and make new
>>> clones where they already are clones and just copy as new nodes
>>> everywhere else?
>>>
>>> Might it be an easy enough rule to say that:
>>
>> It is easier said than done. When you copy an outline part, Leo stores on
>> the clipboard selected nodes along with their gnx fields. When pasting
>> those gnx fields can be re-assigned to new values (when doing an ordinary
>> paste command) or they can be left unchanged (when doing
>> paste-retaining-clones). Nodes for which all clone instances are inside
>> the copied tree have all the information (required to keep them as clones of
>> each other) inside the clipboard content. However, nodes that have clones
>> outside the copied outline have parents that the clipboard content
>> doesn't know at all. Therefore some required information is lost. The
>> paste-as-template command will have hard time to distinguish which of
>> these nodes should be retained and which should be re-instantiated.


I think there's no need to see the parents of the nodes that clone
outside the copied outline.  You just need to know any given node's
vnode.  The simple approach is if there are more than one of the same
vnode in the outline you've grabbed to paste-as-template, those all
get a new vnode and become clone-nodes pointing to that instead.  If
they are loners within the outline you've grabbed, make them plain,
non-clone nodes.  That's for template-as-encapsulated.  The other
type, template-as-global, just makes all clones in the grabbed bit
into new clones in the pasted template, pointing to the same vnode as
the source clones, regardless of where and how many places internal or
external to the grabbed bit those clones may occur.  By my limited
understanding, if you don't have vnodes immediately in the clipboard,
depending on how things work, you may not even need to look up the
vnodes for this "template-as-global" mode.

(eom) (think I've explained enough for now, promise to ponder and wait
in case I'm wrong on this.  Still need to more carefully consider your
comments, too.  Just so you also consider whether you might be making
the task needlessly complex  :-)  )

> See my suggested template-with-encapsulated-clones vs
> template-with-global-clones suggestion I just put on one of Edward's
> comments.  It seems to me that "encapsulating" means make a new vnode
> for all sets of more than one clone-node within the tree that point to
> the same vnode.  The alternative is about not worrying about what
> vnode they link to, just make a new clone that's "global."
>
> I don't fully follow the details you're giving, but I also think
> there's some sort of attempt to figure out logic based on tree
> structure, with parent nodes, how many places they are in the outline,
> considering the original node, etc., at work in your description of
> the problem.
>
> Speaking roughly, I think regardless of the structure of the tree
> you've put in the clipboard, you can identify some that are clones of
> each other within the tree -- can't you look at vnodes to see the
> clones?  Then generate a new vnode for those sets of nodes pointing at
> the same vnode, regardless of where and how many other places nodes
> linked to that vnode occur in the leo outline?
>
> This pair of template operations seems to be a good conceptual
> approach to giving users the ability to take charge of how they want
> the cloning to happen.
>
> Sounds like the clipboard copy is built from gnx's and doesn't have
> immediate info regarding vnodes.  But surely the vnodes can be
> identified.  Then isn't the complexity eliminated?
>
> I will read you more carefully to see whether I'm missing something.
> Might it be simpler than you think?  Anyway, I'll pipe up again if I
> get a better clue and find it necessary to straighten myself out.  :-)
>
>
> Seth
>
>> It is not possible to use just the gnx value to distinguish which nodes
>> were previously clones because all of the copied nodes might have the
>> original node still present in the outline or in the undo data and every
>> node will look like it should be cloned.
>>
>> It isn't possible either to just use the number of parents of the
>> existing
>> nodes to see if they should be retained because children of clones don't
>> need to have more than one parent node, but they still can be found on
>> several places in the outline and therefore they should be cloned.
>>
>> Using marked bit of each node can help to simplify this task of
>> distinguishing which nodes should retain their identity and which should
>> not.
>>
>> Vitalije
>>
>> --
>> 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 

Re: On the Semantics of Copying Clones

[Edward K. Ream]

On Wed, May 27, 2020 at 6:34 AM vitalije  wrote:

> Mark bits are really relevant only when copying node. After the copy has
> been made, the information which nodes were marked is on the clipboard and
> therefore is available to the paste-retaining-marked command. Even after
> unmark-all command as long as the clipboard is not changed,
> paste-retaining-marked will do its job correctly.
>
> Of course there can be assigned another flag for this purpose but I've
> never used marks for anything else but for clone-marked-nodes command.
> Perhaps there is something else that this flag can be used for but I am not
> aware of it. If its main purpose is to mark nodes user wish to clone in the
> future, then it seems to me a fair use case for this command.
>

I agree.

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 leo-editor+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/CAMF8tS0nZZ1QzUy3wbtLWsSMo4gZV%2BBcCg9fXPyO7DLQVJO%2BuQ%40mail.gmail.com.

Re: On the Semantics of Copying Clones

[Seth Johnson]

On 5/27/20, Edward K. Ream  wrote:
> On Wed, May 27, 2020 at 6:17 AM Seth Johnson 
> wrote:
>
>> I would suggest two kinds of paste-as-template
>
> Let's leave such complications until we know there actually will be a
> paste-as-template command.


Okay, but I think my suggestion is simpler conceptually to what folks
seem to be going over, trying to figure out complex logic for
analyzing the tree.

Based on my current understanding of vitalije's comments, I think that
the only important thing is whether you can identify where several
cloned nodes in the paste-as-template are pointing to the same vnode.
Then you just the paste with a new vnode for those nodes in the tree
being pasted-as-template.  That's for template-as-encapsulated,
"local/internal" clones.  The other thing is even more simple, where
the clone nodes just become new clones pointing to the same vnode.
Template-as-global.

If this is right, that you can see where several cloned nodes in the
paste-as-template are pointing to the same vnode, then try reading my
suggestion again.  Maybe you're making it needlessly complex.
However, I will also read vitalije's comments more to see if I'm
missing a clue.  :-)


Seth


> 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 leo-editor+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/leo-editor/CAMF8tS1es1FBATAhZZq%2BA7OOA9TEs6HQAVQJ%3DqrvROZdMN_ZWQ%40mail.gmail.com.
>

-- 
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 leo-editor+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/CAJkfFBza2CqDixOyspJv6Yw%3DSpDDODxDE-e8HVOTvLyZE8D82Q%40mail.gmail.com.

Re: On the Semantics of Copying Clones

[Seth Johnson]

On 5/27/20, vitalije  wrote:
> @Differance
>
> On Wednesday, May 27, 2020 at 11:56:57 AM UTC+2, Differance wrote:
>>
>> Couldn't a paste-as-template just traverse the tree and make new
>> clones where they already are clones and just copy as new nodes
>> everywhere else?
>>
>> Might it be an easy enough rule to say that:
>
> It is easier said than done. When you copy an outline part, Leo stores on
> the clipboard selected nodes along with their gnx fields. When pasting
> those gnx fields can be re-assigned to new values (when doing an ordinary
> paste command) or they can be left unchanged (when doing
> paste-retaining-clones). Nodes for which all clone instances are inside the
> copied tree have all the information (required to keep them as clones of
> each other) inside the clipboard content. However, nodes that have clones
> outside the copied outline have parents that the clipboard content doesn't
> know at all. Therefore some required information is lost. The
> paste-as-template command will have hard time to distinguish which of these
> nodes should be retained and which should be re-instantiated.


See my suggested template-with-encapsulated-clones vs
template-with-global-clones suggestion I just put on one of Edward's
comments.  It seems to me that "encapsulating" means make a new vnode
for all sets of more than one clone-node within the tree that point to
the same vnode.  The alternative is about not worrying about what
vnode they link to, just make a new clone that's "global."

I don't fully follow the details you're giving, but I also think
there's some sort of attempt to figure out logic based on tree
structure, with parent nodes, how many places they are in the outline,
considering the original node, etc., at work in your description of
the problem.

Speaking roughly, I think regardless of the structure of the tree
you've put in the clipboard, you can identify some that are clones of
each other within the tree -- can't you look at vnodes to see the
clones?  Then generate a new vnode for those sets of nodes pointing at
the same vnode, regardless of where and how many other places nodes
linked to that vnode occur in the leo outline?

This pair of template operations seems to be a good conceptual
approach to giving users the ability to take charge of how they want
the cloning to happen.

Sounds like the clipboard copy is built from gnx's and doesn't have
immediate info regarding vnodes.  But surely the vnodes can be
identified.  Then isn't the complexity eliminated?

I will read you more carefully to see whether I'm missing something.
Might it be simpler than you think?  Anyway, I'll pipe up again if I
get a better clue and find it necessary to straighten myself out.  :-)


Seth

> It is not possible to use just the gnx value to distinguish which nodes
> were previously clones because all of the copied nodes might have the
> original node still present in the outline or in the undo data and every
> node will look like it should be cloned.
>
> It isn't possible either to just use the number of parents of the existing
> nodes to see if they should be retained because children of clones don't
> need to have more than one parent node, but they still can be found on
> several places in the outline and therefore they should be cloned.
>
> Using marked bit of each node can help to simplify this task of
> distinguishing which nodes should retain their identity and which should
> not.
>
> Vitalije
>
> --
> 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 leo-editor+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/leo-editor/eae72108-af6e-48a2-879e-43672a5614b4%40googlegroups.com.
>

-- 
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 leo-editor+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/CAJkfFBwjDqbgJVdC5Z9gL0SFmEMZK__nn4oFXEd3%3D6emwk9_3Q%40mail.gmail.com.

Re: On the Semantics of Copying Clones

[vitalije]

Mark bits are really relevant only when copying node. After the copy has 
been made, the information which nodes were marked is on the clipboard and 
therefore is available to the paste-retaining-marked command. Even after 
unmark-all command as long as the clipboard is not changed, 
paste-retaining-marked will do its job correctly.

Of course there can be assigned another flag for this purpose but I've 
never used marks for anything else but for clone-marked-nodes command. 
Perhaps there is something else that this flag can be used for but I am not 
aware of it. If its main purpose is to mark nodes user wish to clone in the 
future, then it seems to me a fair use case for this command. 

Vitalije

-- 
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 leo-editor+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/20a753d3-1373-41b6-9dda-00fbbc808ad8%40googlegroups.com.

Re: On the Semantics of Copying Clones

[Edward K. Ream]

On Wed, May 27, 2020 at 6:17 AM Seth Johnson 
wrote:

> I would suggest two kinds of paste-as-template

Let's leave such complications until we know there actually will be a
paste-as-template command.

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 leo-editor+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/CAMF8tS1es1FBATAhZZq%2BA7OOA9TEs6HQAVQJ%3DqrvROZdMN_ZWQ%40mail.gmail.com.

Re: On the Semantics of Copying Clones

[Edward K. Ream]

On Wed, May 27, 2020 at 6:18 AM Thomas Passin  wrote:

> Using the marked flag might not work as expected, because it might already
> have been set for some other reason.  Perhaps a  node should have a new
> flag denoting its cloned status.
>

Let's keep is simple. Marking is good enough for design work.

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 leo-editor+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/CAMF8tS3ak4HyZofCzDTZz9_m6FgmuhZKXQiaqCeDmiBf2LHTpg%40mail.gmail.com.

Re: On the Semantics of Copying Clones

[Edward K. Ream]

On Wed, May 27, 2020 at 6:01 AM vitalije  wrote:

we need a new copy command, after which the paste-retaining-clones command
> can be used as is.
>

I doubt that. The paste-retaining-clones will not change anything from the
clipboard content, but the user will expect this command to create new
nodes at least for some of the copied tree. If you devise a new
copy-template function, then after the first paste-retaining-clones
execution every next execution will create just the clone of the outline
pasted the first time i.e. all nodes will be cloned not just some of them.

Good point. The user could do a second copy-template, but that would be
clumsy.

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 leo-editor+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/CAMF8tS1ZG4W8CL1Wp4m_kn9ruGGksoC3FqamBqp1%2B29D5ssxKA%40mail.gmail.com.

Re: On the Semantics of Copying Clones

[John Clark]

>From reading the recent messages I'm quickly developing an appreciation for 
all these edge cases.

When I'm coding (which is not very often these days), this raises my 
"spidey sense" that there is a much more elegant solution lurking 
somewhere. 

The node marking approach may well be "it". Makes a lot of sense. Although 
this does repurpose the node marking feature a little, does it not? Which 
nodes are marked and which aren't now matters for desired templating 
behaviour, but node marking still plays the other roles it's had until now. 
Consequently, "unmark all nodes" now has an undesirable side effect if one 
has templates in their tree. That could be worked around with a little 
scripting (perhaps a little script to re-mark the desired nodes in the 
template). But then as I type the last sentence the thought occurs to me 
that I could just write a script to generate a copy of a template precisely 
how I like/need.

Hmmm


-- 
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 leo-editor+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/34626ed4-609b-40f7-bf69-289348de5fc1%40googlegroups.com.

Re: On the Semantics of Copying Clones

[Thomas Passin]

Using the marked flag might not work as expected, because it might already 
have been set for some other reason.  Perhaps a  node should have a new 
flag denoting its cloned status.  The complication would be that when a 
node marked as a clone gets deleted, the outline has to be checked to see 
if there are other clones still in existence.  if not, then its clone flag 
would get unset.

On Wednesday, May 27, 2020 at 6:51:27 AM UTC-4, vitalije wrote:
>
> @Differance
>
> On Wednesday, May 27, 2020 at 11:56:57 AM UTC+2, Differance wrote:
>>
>> Couldn't a paste-as-template just traverse the tree and make new 
>> clones where they already are clones and just copy as new nodes 
>> everywhere else? 
>>
>> Might it be an easy enough rule to say that: 
>>   
>>
>  
> It is easier said than done. When you copy an outline part, Leo stores on 
> the clipboard selected nodes along with their gnx fields. When pasting 
> those gnx fields can be re-assigned to new values (when doing an ordinary 
> paste command) or they can be left unchanged (when doing 
> paste-retaining-clones). Nodes for which all clone instances are inside the 
> copied tree have all the information (required to keep them as clones of 
> each other) inside the clipboard content. However, nodes that have clones 
> outside the copied outline have parents that the clipboard content doesn't 
> know at all. Therefore some required information is lost. The 
> paste-as-template command will have hard time to distinguish which of these 
> nodes should be retained and which should be re-instantiated.
>
> It is not possible to use just the gnx value to distinguish which nodes 
> were previously clones because all of the copied nodes might have the 
> original node still present in the outline or in the undo data and every 
> node will look like it should be cloned.
>
> It isn't possible either to just use the number of parents of the existing 
> nodes to see if they should be retained because children of clones don't 
> need to have more than one parent node, but they still can be found on 
> several places in the outline and therefore they should be cloned.
>
> Using marked bit of each node can help to simplify this task of 
> distinguishing which nodes should retain their identity and which should 
> not.
>
> Vitalije
>

-- 
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 leo-editor+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/3b6628c8-5e1a-4396-9003-bab4c1cf9d4b%40googlegroups.com.

Re: On the Semantics of Copying Clones

[Seth Johnson]

On 5/27/20, Edward K. Ream  wrote:
> On Wed, May 27, 2020 at 12:56 AM John Clark 
>> For brevity, I denote clones that are internal to the source tree only as
>> "local clones". In the templating use case, I think there's a strong case
>> to be made for NOT linking local clones under the source node in the the
>> copied tree. Doing so allows provisioning of clones internally in the
>> source "template" that define content that is shared around the children
>> of the template, but is likely to be different in deployments (copies) of
>> that template.
>>
>> I hope that makes sense.
>>
>
> Yes, that makes sense to me. It's a bit different from either of the two
> options I gave, but that shouldn't matter. It should be doable.
>
> Note: depending on where (and how!) you copy node Y, the external clone of
> X3 might not turn out to be a clone. This will happen if you don't copy Y
> to the original outline, but rather to an outline that doesn't contain a
> node X3 with the same gnx as the copied node X3.


Ah!  That would be cool: internal/local clones become a new vnode in
the new template.

This is for John's use case, but I would suggest two kinds of
paste-as-template --

a) template-with-encapsulated-clones, where the new template tree
makes new vnodes to represent any internal clones it finds, rendering
the template "independent" or encapsulated

b) and template-with-global-clones, a simpler case where plain nodes
become new copies and for all clones you just make another pointer to
the same vnode as in the original tree being templated.

I guess the detection of internal/local clones could be defined in
different ways.  It could be any clones that happen more than once in
the tree become internal/local and generate a new vnode.

But then the question of what happens to clones that occur once in the
tree remains -- do they remain "global", links to the vnode in the
original tree, or do they become plain, new copied nodes?  Becoming
new copied nodes instead of new "global" clones seems to make sense
from the standpoint of the notion of creating "encapsulated"
templates.

Seems to me people could work with that type of pair of template
operations, handling the decision of where they want global clones by
manually pasting as clone or templating-with-global-clones wherever
they want to put in global clones.  They'd see lone external clones
"disconnect" as they template-with-encapsulated-clones and recognize
what's happening and then they'd just take responsibility for those by
coming back in and pasting just those clones as global, even within
templates they've already pasted-as-encapsulated.

BTW, they're all "global" clones in the end, just some new ones get
created if you choose to paste-as-encapsulated.  The idea of local
clones only pertains to the moment of creating the template.

The alternative would seem to me to involve creating a new kind of
"local" clone, specially designated as such, which seems unnecessary.


Seth

>
> 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 leo-editor+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/leo-editor/CAMF8tS3NRF3brXppvDBNYsx4PvF1n3OHsByKOKhUOJ72XEPvLQ%40mail.gmail.com.
>

-- 
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 leo-editor+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/CAJkfFBx8EVhjBdOTuPd1PWBt-P%2B9prk0wMjJOKG%2BZTPjJa1g%3DA%40mail.gmail.com.

Re: On the Semantics of Copying Clones

[Thomas Passin]

On Wednesday, May 27, 2020 at 6:44:56 AM UTC-4, Edward K. Ream wrote:
>
>
> *CONCLUSION*:
>> Thomas really needs '*include*' of the code snippet instead of cloned 
>> code. Clones are no good for his case.
>>
>
To the contrary, clones are exactly what I want.  These are code shared by 
a number of similar programs.  If I fix a bug or make an improvement in 
one, I want it to happen in all of those programs.  If I were not using 
Leo, I'd put these nodes into a little python file and import it.  But with 
Leo, I don't have to manage yet another file nor remember where it is in 
the future, nor make sure it's on the python path.

Clones are what I want.


> Thanks for these comments. Imo, marking desired cloned nodes when 
> *copying* the template should allow the user to specify exactly what they 
> want. The user can just do paste-retaining-clones.
>
> 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 leo-editor+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/8dc0ac17-a715-415e-a374-6580baab9e87%40googlegroups.com.

Re: On the Semantics of Copying Clones

[vitalije]

On Wednesday, May 27, 2020 at 12:39:56 PM UTC+2, Edward K. Ream wrote:
>
> On Wed, May 27, 2020 at 4:56 AM Seth Johnson  > wrote:
>
> Couldn't a paste-as-template just traverse the tree and make new
>> clones where they already are clones and just copy as new nodes
>> everywhere else?
>>
>
> Much easier said than done, as I recently discovered.
>

He, he we have started our replies with the same words. 
  

> we need a new copy command, after which the paste-retaining-clones command 
> can be used as is.
>
>
I doubt that. The paste-retaining-clones will not change anything from the 
clipboard content, but the user will expect this command to create new 
nodes at least for some of the copied tree. If you devise a new 
copy-template function, then after the first paste-retaining-clones 
execution every next execution will create just the clone of the outline 
pasted the first time i.e. all nodes will be cloned not just some of them.

Vitalije

-- 
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 leo-editor+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/4f15976a-daff-4190-aa8f-1e4fa72991ce%40googlegroups.com.

Re: On the Semantics of Copying Clones

[vitalije]

@Differance

On Wednesday, May 27, 2020 at 11:56:57 AM UTC+2, Differance wrote:
>
> Couldn't a paste-as-template just traverse the tree and make new 
> clones where they already are clones and just copy as new nodes 
> everywhere else? 
>
> Might it be an easy enough rule to say that: 
>   
>
 
It is easier said than done. When you copy an outline part, Leo stores on 
the clipboard selected nodes along with their gnx fields. When pasting 
those gnx fields can be re-assigned to new values (when doing an ordinary 
paste command) or they can be left unchanged (when doing 
paste-retaining-clones). Nodes for which all clone instances are inside the 
copied tree have all the information (required to keep them as clones of 
each other) inside the clipboard content. However, nodes that have clones 
outside the copied outline have parents that the clipboard content doesn't 
know at all. Therefore some required information is lost. The 
paste-as-template command will have hard time to distinguish which of these 
nodes should be retained and which should be re-instantiated.

It is not possible to use just the gnx value to distinguish which nodes 
were previously clones because all of the copied nodes might have the 
original node still present in the outline or in the undo data and every 
node will look like it should be cloned.

It isn't possible either to just use the number of parents of the existing 
nodes to see if they should be retained because children of clones don't 
need to have more than one parent node, but they still can be found on 
several places in the outline and therefore they should be cloned.

Using marked bit of each node can help to simplify this task of 
distinguishing which nodes should retain their identity and which should 
not.

Vitalije

-- 
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 leo-editor+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/eae72108-af6e-48a2-879e-43672a5614b4%40googlegroups.com.

Re: On the Semantics of Copying Clones

[Edward K. Ream]

> *CONCLUSION*:
> Thomas really needs '*include*' of the code snippet instead of cloned
> code. Clones are no good for his case.
>

Thanks for these comments. Imo, marking desired cloned nodes when *copying*
the template should allow the user to specify exactly what they want. The
user can just do paste-retaining-clones.

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 leo-editor+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/CAMF8tS1w1spATgsNuMZFNK-pnKpTQ6zDv8uttpXqB6nKVp4PvQ%40mail.gmail.com.

Re: On the Semantics of Copying Clones

[Edward K. Ream]

On Wed, May 27, 2020 at 4:56 AM Seth Johnson 
wrote:

Couldn't a paste-as-template just traverse the tree and make new
> clones where they already are clones and just copy as new nodes
> everywhere else?
>

Much easier said than done, as I recently discovered. The FastRead class
handles copied outlines. This class wasn't designed for the task at hand.
As I said in another response, we need a new copy command, after which the
paste-retaining-clones command can be used as is.

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 leo-editor+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/CAMF8tS0ooqm%3DghUP7GzYHsNYwxY3HU-i%3DxWiAqn-5%3D3-1uqBsg%40mail.gmail.com.

Re: On the Semantics of Copying Clones

[Edward K. Ream]

On Wed, May 27, 2020 at 2:08 AM vitalije  wrote:

Personally I have felt (more than once) a need for this kind of command in
> the past. It is hard to make a simple rule that this command should follow
> to decide which nodes to clone and which nodes to copy. Whatever rule we
> decide on, it will lead to ambiguous situations  when tree changes between
> copy and paste command.
>

I agree. I hadn't thought about this case.

Perhaps this can be simplified to this command:
> `paste-retaining-marked-nodes`. User can mark nodes that are to be
> retaining identity after paste. All other nodes should have new identities
> after paste. I guess this would be trivial to implement and user would have
> full power over the effect of the command.
>

An excellent idea.

At present, I am leaning towards adding a new copy command, rather than a
new paste command. The user would do, say, copy-retaining-marked-clones,
followed by the usual paste-retaining clones. It's a lot easier to
customize writing than to customize reading.

copy-retaining-marked-clones would create new, unique gnx's for all nodes
except marked clones. This makes the cloned property in the *original*
(template) tree determinative, which seems reasonable.

Creating another version of paste-retaining-nodes would be difficult. Leo's
copy-node command retains all gnx's. The paste-node eventually ignores
those gnx's. The paste-retaining-clones does not. It's an either-or thing,
driven by the gnxDict.

An experiment that added only some gnx's to that dict failed. Separate
vnodes got the same gnx.  Fortunately, Leo caught that problem. Trying to
tell the FastRead class to follow a mixed strategy would likely be
difficult and error prone. Or so I think now.

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 leo-editor+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/CAMF8tS2km%2BfhuCy%2Bcicmt-7BJLfSTuqa%3Dzg-ivDub%3DEpsUESyA%40mail.gmail.com.

Re: On the Semantics of Copying Clones

[Edward K. Ream]

On Wed, May 27, 2020 at 1:08 AM John Clark 
wrote:

> Please note I edited my earlier post to clear up some potential
> ambiguities.
>
> Also, after posting I realized that I also needed to clarify that a clone
> in the source tree is only considered to be a local clone if it has no
> clones outside the source tree, in which case those nodes in the duplicated
> tree will be cloned within the duplicated tree but distinct from the source
> tree. So a source tree that contains multiple clones within the source tree
> but also at least one clone outside the source tree is NOT considered a
> local clone for our purposes. So these clones in the copied tree will be
> also be clones of those nodes in the source tree.
>

Thanks for the clarification. It's the reasonable default, imo.

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 leo-editor+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/CAMF8tS3Lh4kctoFbsB4mUngU52b%2BC7uHPtcvPysvWSivxZOm%3Dg%40mail.gmail.com.

Re: On the Semantics of Copying Clones

[Edward K. Ream]

On Wed, May 27, 2020 at 12:56 AM John Clark 
wrote:

I'm going to assume you made a typo in your reference to A2, because A2 is
> not involved in the proposed clone-preserving copy-and-paste.
>

Right. I meant A1 and A3.

> Nevertheless, I think a further expansion on my original example is in
> order, this time including nodes that are cloned internally to the source
> tree to facilitate discussion of that case. I'll use different naming to
> avoid confusion.
>
> Suppose I start with this:
>
> Node X
>  + Node X1
>  + Node X2
>  + Node X3
>
>
> I then build a new tree, called Node Y, with some children that are unique
> and some that are clones of the children of Node X, resulting in the tree
> as shown below. Note I've put comments in to clearly identify the clones.
> We could call Node Y our "template":
>
> Node X
>  + Node X1
>  + Node X2
>  + Node X3
> Node Y
>  + Node Y1  # an "internal" clone of Y1 below
>  + Node Y2
>+ Node Y1# an "internal" clone of Y1 above
>  + Node Y3
>+ Node X3# an "external" clone of X3 which is under Node X
>
> Now I've built my "template", rooted at Node Y, I want to put it to use by
> making a "copy preserving clones" of it. Now, as you rightly note, here
> arises the question of what to do about clones that are purely local to the
> source node. I've thought about it in the sense of the templating use case,
> and this is what I believe the behaviour should be:
>
> Node X
>  + Node X1
>  + Node X2
>  + Node X3
> Node Y
>  + Node Y1  # an "internal" clone of Y1 below
>  + Node Y2
>+ Node Y1# an "internal" clone of Y1 above
>  + Node Y3
>+ Node X3# an "external" clone of X3 which is under Node X
> Node Y
>  + Node Y1  # a copy, but an internal clone of Node Y1 (below)
>  + Node Y2  # a copy
>+ Node Y1# a copy, but an internal clone of Node Y1 (above)
>  + Node Y3  # a copy
>+ Node X3# an "external" clone of X3 which is under Node X
>
>
> For brevity, I denote clones that are internal to the source tree only as
> "local clones". In the templating use case, I think there's a strong case
> to be made for NOT linking local clones under the source node in the the
> copied tree. Doing so allows provisioning of clones internally in the
> source "template" that define content that is shared around the children of
> the template, but is likely to be different in deployments (copies) of that
> template.
>
> I hope that makes sense.
>

Yes, that makes sense to me. It's a bit different from either of the two
options I gave, but that shouldn't matter. It should be doable.

Note: depending on where (and how!) you copy node Y, the external clone of
X3 might not turn out to be a clone. This will happen if you don't copy Y
to the original outline, but rather to an outline that doesn't contain a
node X3 with the same gnx as the copied node X3.

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 leo-editor+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/CAMF8tS3NRF3brXppvDBNYsx4PvF1n3OHsByKOKhUOJ72XEPvLQ%40mail.gmail.com.

Re: On the Semantics of Copying Clones

[Seth Johnson]

On 5/27/20, Seth Johnson  wrote:
> Couldn't a paste-as-template just traverse the tree and make new
> clones where they already are clones and just copy as new nodes
> everywhere else?
>
> Might it be an easy enough rule to say that:
>
> a) pasting a whole tree as a clone makes the tree a clone at the
> topmost node (and would turn the source tree's topmost node into a
> clone if it isn't already) (what's currently implemented)
>
> b) whereas pasting a whole tree as a template doesn't make any nodes
> into brand new clones (topmost or below); it just clones what's
> already a clone below the topmost node?
>
> Isn't it the case that clones are really just the same node
> represented on screen in different places at the same time, with
> pointers from different places in the data structure?  I could be
> wrong, but seems like for paste-as-template only clones become new
> clones in the new template tree, and so there won't be any need to
> keep track of any effects of dependencies on source nodes in the
> original tree.
>
> An original tree clone node would revert to regular clone only when

. . . would revert to regular NODE only when . .

(eom)

> you delete the last cloned instance somewhere else.  But that's
> already built in, happens every time you delete anything.  You can
> even add to or prune individual template trees willy-nilly that were
> identical to each other when they were originally pasted-as-template.
>
>
> Seth
>
>
> On 5/27/20, vitalije  wrote:
>> I am rather busy ATM so I can't help much with this. Personally I have
>> felt
>> (more than once) a need for this kind of command in the past. It is hard
>> to
>> make a simple rule that this command should follow to decide which nodes
>> to
>> clone and which nodes to copy. Whatever rule we decide on, it will lead
>> to
>> ambiguous situations  when tree changes between copy and paste command.
>>
>> Perhaps this can be simplified to this command:
>> `paste-retaining-marked-nodes`. User can mark nodes that are to be
>> retaining identity after paste. All other nodes should have new
>> identities
>> after paste. I guess this would be trivial to implement and user would
>> have
>> full power over the effect of the command.
>>
>> Vitalije
>

-- 
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 leo-editor+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/CAJkfFBwMO7VL0xyKHvySALvxkiNJLdPVrLkJDDfzvRsPVj%2BhvA%40mail.gmail.com.

Re: On the Semantics of Copying Clones

[Edward K. Ream]

On Tue, May 26, 2020 at 10:09 PM Mike Hodson  wrote:

Said simpler:
> Does cloning a normal node, make BOTH nodes clones?
>

Yes. In fact, making a clone of a node just creates a new link to it. There
is actually only a single vnode.

> Or is there still an idea of "this is the original" (A>A1) and "this is a
> clone of the original" (B>A1)
>

There is no notion of "original" node, nor is there a notion of the
original link to the node. There is just a single vnode and multiple parent
links to that node.

We could, if we like, define the following notion. N is a *local clone of B*
if and only if:

- Node N is a clone,
- Node N is a descendant of B,
- N has two or more parents Pi such that each Pi is a descendant of B.

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 leo-editor+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/CAMF8tS22C7nDEhXcZr3KnwZ5TaFe_iT0rGBBEA1shvgjydUaCQ%40mail.gmail.com.

Re: On the Semantics of Copying Clones

[Seth Johnson]

Couldn't a paste-as-template just traverse the tree and make new
clones where they already are clones and just copy as new nodes
everywhere else?

Might it be an easy enough rule to say that:

a) pasting a whole tree as a clone makes the tree a clone at the
topmost node (and would turn the source tree's topmost node into a
clone if it isn't already) (what's currently implemented)

b) whereas pasting a whole tree as a template doesn't make any nodes
into brand new clones (topmost or below); it just clones what's
already a clone below the topmost node?

Isn't it the case that clones are really just the same node
represented on screen in different places at the same time, with
pointers from different places in the data structure?  I could be
wrong, but seems like for paste-as-template only clones become new
clones in the new template tree, and so there won't be any need to
keep track of any effects of dependencies on source nodes in the
original tree.

An original tree clone node would revert to regular clone only when
you delete the last cloned instance somewhere else.  But that's
already built in, happens every time you delete anything.  You can
even add to or prune individual template trees willy-nilly that were
identical to each other when they were originally pasted-as-template.


Seth


On 5/27/20, vitalije  wrote:
> I am rather busy ATM so I can't help much with this. Personally I have felt
> (more than once) a need for this kind of command in the past. It is hard to
> make a simple rule that this command should follow to decide which nodes to
> clone and which nodes to copy. Whatever rule we decide on, it will lead to
> ambiguous situations  when tree changes between copy and paste command.
>
> Perhaps this can be simplified to this command:
> `paste-retaining-marked-nodes`. User can mark nodes that are to be
> retaining identity after paste. All other nodes should have new identities
> after paste. I guess this would be trivial to implement and user would have
> full power over the effect of the command.
>
> Vitalije

-- 
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 leo-editor+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/CAJkfFByR9KP3mKcqzh9jGbTybRrfmJuC2n4BG9L6Kjmrx9uDRA%40mail.gmail.com.

Re: On the Semantics of Copying Clones

[T . Vlainić]

*Sample:*

Leo file LF1 

> Node A
>  + Node A1 (a clone)
>  + Node A2
>  + Node A3 (a clone)
> Node B
>  + Node A1 (a clone)
>  + Node B2
>+ Node A3 (a clone)
>

*COPY NODE WITH PRESERVED CLONES *

if Node B is copied within LF1 into Node C

> Node A
>  + Node A1 (a clone)
>  + Node A2
>  + Node A3 (a clone)
> Node B
>  + Node A1 (a clone)
>  + Node B2
>+ Node A3 (a clone)
> Node C
>  + Node A1 (a clone)
>  + Node B2
>+ Node A3 (a clone)
>
> *STORY*:
1) If Node A, Node B and Node C are in separate @files nodes within LF1:

@file FA 
 + Node A
@file FB 
 + Node B
@file FC
 + Node C


=>Everything is Ok if FA, FB and FC are within LF1 only.

2) If @file FC is also in leo file LF2 and node Node A1 edited in LF2

or

if file FC is edited in another editor 

=> cloned code will be messy

*CONCLUSION*:
Thomas really needs '*include*' of the code snippet instead of cloned code. 
Clones are no good for his case.


Tomislav

-- 
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 leo-editor+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/b010e545-71f6-428d-8197-722e8d49cb60%40googlegroups.com.

Re: On the Semantics of Copying Clones

[vitalije]

I am rather busy ATM so I can't help much with this. Personally I have felt 
(more than once) a need for this kind of command in the past. It is hard to 
make a simple rule that this command should follow to decide which nodes to 
clone and which nodes to copy. Whatever rule we decide on, it will lead to 
ambiguous situations  when tree changes between copy and paste command.

Perhaps this can be simplified to this command: 
`paste-retaining-marked-nodes`. User can mark nodes that are to be 
retaining identity after paste. All other nodes should have new identities 
after paste. I guess this would be trivial to implement and user would have 
full power over the effect of the command.

Vitalije

-- 
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 leo-editor+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/5ec76be4-4835-4e5f-a97b-34403e874774%40googlegroups.com.

Re: On the Semantics of Copying Clones

[John Clark]

Please note I edited my earlier post to clear up some potential 
ambiguities. 

Also, after posting I realised that I also needed to clarify that a clone 
in the source tree is only considered to be a local clone if it has no 
clones outside the source tree, in which case those nodes in the duplicated 
tree will be cloned within the duplicated tree but distinct from the source 
tree. So a source tree that contains multiple clones within the source tree 
but also at least one clone outside the source tree is NOT considered a 
local clone for our purposes. So these clones in the copied tree will be 
also be clones of those nodes in the source tree.

Cheers

-- 
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 leo-editor+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/d164bcc0-c59e-469e-9135-13274859a4da%40googlegroups.com.

Re: On the Semantics of Copying Clones

[John Clark]

On Wednesday, May 27, 2020 at 1:01:53 PM UTC+10, Edward K. Ream wrote:
>
> On Saturday, May 23, 2020 at 2:36:21 AM UTC-5, John Clark wrote:
>
> I have started work on #1593 
> . It is tricky. 
> Some initial experiments failed spectacularly.
>
> Instead of using a copy-node followed by the new paste-as-template 
> command, it *might *be better to create a new copy-as-template followed 
> by the existing paste-retaining-clones commands. So let's use the term 
> "copy and paste" to denote whatever commands turn out to be best.
>  
>
>> Let's say we have a tree like below. Note that all nodes are NOT clones 
>> unless specifically stated:
>>
>> Node A
>>  + Node A1
>>  + Node A2
>>  + Node A3
>> Node B
>>  + Node A1 (a clone)
>>  + Node B2
>>+ Node A3 (a clone)
>>
>
> There is a problem in your example. A1 and A2 can't be clones in node B 
> unless A1 and A3 are clones in Node A (or somewhere else). Did you mean 
> that A1 and A2 in A should also be clones? It makes a difference.
>
> This question is: "what nodes should be clones after the copy and paste?"  
> There are at least two possible answers:
>
> 1. [non-local] *All* nodes in B that were clones when B was copied, 
> provided that they could again be clones after being pasted.
>
> 2. [local] Only nodes in B that were clones of *other* nodes in B when 
> the copy was made.
>
> I infer answer 1 if A1 and A3 in A should have been labeled "a clone". 
> Otherwise, I infer answer 2.
>
> Either way can be made to work, but I would like your answer before going 
> further. I am particularly interested in some examples of how this kind of 
> templating would be useful for you.
>
> Edward
>

I'm going to assume you made a typo in your reference to A2, because A2 is 
not involved in the proposed clone-preserving copy-and-paste. Nevertheless, 
I think a further expansion on my original example is in order, this time 
including nodes that are cloned internally to the source tree to facilitate 
discussion of that case. I'll use different naming to avoid confusion.

Suppose I start with this:

Node X
 + Node X1
 + Node X2
 + Node X3


I then build a new tree, called Node Y, with some children that are unique 
and some that are clones of the children of Node X, resulting in the tree 
as shown below. Note I've put comments in to clearly identify the clones. 
We could call Node Y our "template":

Node X
 + Node X1
 + Node X2
 + Node X3
Node Y
 + Node Y1  # an "internal" clone of Y1 below
 + Node Y2
   + Node Y1# an "internal" clone of Y1 above
 + Node Y3
   + Node X3# an "external" clone of X3 which is under Node X

Now I've built my "template", rooted at Node Y, I want to put it to use by 
making a "copy preserving clones" of it. Now, as you rightly note, here 
arises the question of what to do about clones that are purely local to the 
source node. I've thought about it in the sense of the templating use case, 
and this is what I believe the behaviour should be:

Node X
 + Node X1
 + Node X2
 + Node X3
Node Y
 + Node Y1  # an "internal" clone of Y1 below
 + Node Y2
   + Node Y1# an "internal" clone of Y1 above
 + Node Y3
   + Node X3# an "external" clone of X3 which is under Node X
Node Y
 + Node Y1  # a copy, but an internal clone of Node Y1 (below)
 + Node Y2  # a copy
   + Node Y1# a copy, but an internal clone of Node Y1 (above)
 + Node Y3  # a copy
   + Node X3# an "external" clone of X3 which is under Node X


For brevity, I denote clones that are internal to the source tree only as 
"local clones". In the templating use case, I think there's a strong case 
to be made for NOT linking local clones under the source node in the the 
copied tree. Doing so allows provisioning of clones internally in the 
source "template" that define content that is shared around the children of 
the template, but is likely to be different in deployments (copies) of that 
template. 

I hope that makes sense.

John

 


 

-- 
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 leo-editor+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/02b727ef-b1aa-413a-b357-5b4622533e03%40googlegroups.com.

Re: On the Semantics of Copying Clones

[Mike Hodson]

On Tue, May 26, 2020 at 9:01 PM Edward K. Ream  wrote:

> Let's say we have a tree like below. Note that all nodes are NOT clones
>> unless specifically stated:
>>
>> Node A
>>  + Node A1
>>  + Node A2
>>  + Node A3
>> Node B
>>  + Node A1 (a clone)
>>  + Node B2
>>+ Node A3 (a clone)
>>
>
> There is a problem in your example. A1 and A2 can't be clones in node B
> unless A1 and A3 are clones in Node A (or somewhere else). Did you mean
> that A1 and A2 in A should also be clones? It makes a difference.
>
> This question is: "what nodes should be clones after the copy and paste?"
> There are at least two possible answers:
>
> 1. [non-local] *All* nodes in B that were clones when B was copied,
> provided that they could again be clones after being pasted.
>
> 2. [local] Only nodes in B that were clones of *other* nodes in B when
> the copy was made.
>
> I infer answer 1 if A1 and A3 in A should have been labeled "a clone".
> Otherwise, I infer answer 2.
>
>
Maybe I don't understand what a 'clone' entails, and perhaps others are
having the same misconception?

Are you stating that:  If I create a node "node a" and put data in subnode
"node a1" and that if then I decide I want a clone of "node a1" as a
subnode of "node b", that this implicitly 'undoes' the 'regular node
status' of A>A1 and makes A>A1 and B>A1 clones of eachother?

Said simpler:
Does cloning a normal node, make BOTH nodes clones?
Or is there still an idea of "this is the original" (A>A1) and "this is a
clone of the original" (B>A1)

Because your "problem" listed above seems to imply that by cloning a 1
normal node, the result is 2 clones and 0 regular nodes?

Mike

-- 
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 leo-editor+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/CAN%2B%2B4hE8iZDqmCKGPWgfF9UJPJYYZmJo37YYqRPT0i2_RHrrjQ%40mail.gmail.com.

Re: On the Semantics of Copying Clones

[Edward K. Ream]

On Saturday, May 23, 2020 at 2:36:21 AM UTC-5, John Clark wrote:

I have started work on #1593 
. It is tricky. Some 
initial experiments failed spectacularly.

Instead of using a copy-node followed by the new paste-as-template command, 
it *might *be better to create a new copy-as-template followed by the 
existing paste-retaining-clones commands. So let's use the term "copy and 
paste" to denote whatever commands turn out to be best.
 

> Let's say we have a tree like below. Note that all nodes are NOT clones 
> unless specifically stated:
>
> Node A
>  + Node A1
>  + Node A2
>  + Node A3
> Node B
>  + Node A1 (a clone)
>  + Node B2
>+ Node A3 (a clone)
>

There is a problem in your example. A1 and A2 can't be clones in node B 
unless A1 and A3 are clones in Node A (or somewhere else). Did you mean 
that A1 and A2 in A should also be clones? It makes a difference.

This question is: "what nodes should be clones after the copy and paste?"  
There are at least two possible answers:

1. [non-local] *All* nodes in B that were clones when B was copied, 
provided that they could again be clones after being pasted.

2. [local] Only nodes in B that were clones of *other* nodes in B when the 
copy was made.

I infer answer 1 if A1 and A3 in A should have been labeled "a clone". 
Otherwise, I infer answer 2.

Either way can be made to work, but I would like your answer before going 
further. I am particularly interested in some examples of how this kind of 
templating would be useful for you.

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 leo-editor+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/fc8d065d-f679-4ae9-b733-f51df439c7a1%40googlegroups.com.

Re: On the Semantics of Copying Clones

[Thomas Passin]

Thanks, John, you nailed it exactly!

With this functionality, it will be easy to use trees as templates. And 
that turns out to be what I've been doing this week.

On Saturday, May 23, 2020 at 3:36:21 AM UTC-4, John Clark wrote:
>
>
>
> On Saturday, May 23, 2020 at 7:09:20 AM UTC+10, Edward K. Ream wrote:
>>
>>
>>
>> On Fri, May 22, 2020 at 1:06 PM Thomas Passin  wrote:
>>
>> This sounds as if a cloned node in the original tree will end up as a 
>>> cloned node in the final tree.  That is not what I see, though.  The node 
>>> that is a clone in the original tree  becomes a copy (not a clone) in the 
>>> pasted tree.  That would fit in with "new gnx's for all pasted nodes".
>>>
>>
>> You misunderstand me. If there are two (cloned nodes) A in the copied 
>> tree, those clones will be clones *of each other* in any pasted tree, as 
>> I have just verified.
>>
>> It's harder to describe what happens than to verify what happens. I'm 
>> quite sure Leo does the correct thing in all situations.
>>
>
> I want to declare my interest in this subject. I have use cases similar to 
> what it seems Thomas has, which would benefit significantly from the 
> functionality I believe he's seeking. 
>
> Edward, I also think I understand what you're referring to, but I think 
> you are referring to a different concern (preserving the nature of clones 
> that are internal to the tree being copied). I believe Thomas is referring 
> to how clones are handled when copying a tree that contains clones of nodes 
> that are outside the tree being copied. If so, I'm interested in this 
> problem also. Also, I think Thomas is not indicating a bug, but rather 
> enquiring about additional functionality. 
>
> What I think both Thomas and I are interested in achieving is as follows. 
> Let's say we have a tree like below. Note that all nodes are NOT clones 
> unless specifically stated:
>
> [snip]
>

-- 
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 leo-editor+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/44a1b933-a839-4ff6-847a-15ae2feb3d6b%40googlegroups.com.

Re: On the Semantics of Copying Clones

[Xavier G. Domingo (xgid)]

On Saturday, May 23, 2020 at 7:02:46 AM UTC-3, Edward K. Ream wrote:
>
>
> Thanks for this excellent clarification. This should be doable with a a 
> new command, say, paste-retaining-only-clones. I have just created #1593 
>  for this.
>
> Edward
>
 
Thanks Thomas and John for your proposal. This is a feature that I've also 
missed in the past at some point, but never realised it until you raised it 
here.

If I can suggest a name for the command, I would go for 
"paste-retaining-clones". The word "only" there for me its confusing as it 
makes me think that *only the clones* will be pasted, discarding the rest 
of nodes... or anything around this idea.

Xavier

-- 
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 leo-editor+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/b489f3ec-db07-45e1-84cd-3783877645f8%40googlegroups.com.

Re: On the Semantics of Copying Clones

[John Clark]

On Saturday, May 23, 2020 at 8:02:46 PM UTC+10, Edward K. Ream wrote:
>
>
> Thanks for this excellent clarification. This should be doable with a a 
> new command, say, paste-retaining-only-clones. I have just created #1593 
>  for this.
>
>
Wunderbar! 

-- 
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 leo-editor+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/2a74efdd-dd18-4cd4-8bea-cac464c2fdfd%40googlegroups.com.

Re: On the Semantics of Copying Clones

[Edward K. Ream]

On Sat, May 23, 2020 at 2:36 AM John Clark 
wrote:

> Edward, ... I think you are referring to a different concern.
[snip]
> What I think both Thomas and I are interested in achieving is as follows. 
> Let's
say we have a tree like below. Note that all nodes are NOT clones unless
specifically stated:

Node A
 + Node A1
 + Node A2
 + Node A3
Node B
 + Node A1 (a clone)
 + Node B2
   + Node A3 (a clone)

> Now, what I want to do is copy Node B and have the following result:

Node A
 + Node A1
 + Node A2
 + Node A3
Node B
 + Node A1 (a clone)
 + Node B2
   + Node A3 (a clone)
Node B (but this is a copy, not a clone)
 + Node A1 (still a clone)
 + Node B2 (but this is a copy, not a clone)
   + Node A3 (still a clone)

> I would love this functionality, but currently it's not present. I think
there are many use cases for this. I use it for templating-like tasks. But
at the moment it's really clunky to achieve, as I have to use Paste-node
then reinstate the clones. I often miss some and then chaos ensues.

Thanks for this excellent clarification. This should be doable with a a new
command, say, paste-retaining-only-clones. I have just created #1593
 for this.

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 leo-editor+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/CAMF8tS2EyrAYp2JCdhv2f6UvG8vwPe4rSrmYe0NaKt11Z6MU4g%40mail.gmail.com.

Re: On the Semantics of Copying Clones

[John Clark]

On Saturday, May 23, 2020 at 7:09:20 AM UTC+10, Edward K. Ream wrote:
>
>
>
> On Fri, May 22, 2020 at 1:06 PM Thomas Passin  > wrote:
>
> This sounds as if a cloned node in the original tree will end up as a 
>> cloned node in the final tree.  That is not what I see, though.  The node 
>> that is a clone in the original tree  becomes a copy (not a clone) in the 
>> pasted tree.  That would fit in with "new gnx's for all pasted nodes".
>>
>
> You misunderstand me. If there are two (cloned nodes) A in the copied 
> tree, those clones will be clones *of each other* in any pasted tree, as 
> I have just verified.
>
> It's harder to describe what happens than to verify what happens. I'm 
> quite sure Leo does the correct thing in all situations.
>

I want to declare my interest in this subject. I have use cases similar to 
what it seems Thomas has, which would benefit significantly from the 
functionality I believe he's seeking. 

Edward, I also think I understand what you're referring to, but I think you 
are referring to a different concern (preserving the nature of clones that 
are internal to the tree being copied). I believe Thomas is referring to 
how clones are handled when copying a tree that contains clones of nodes 
that are outside the tree being copied. If so, I'm interested in this 
problem also. Also, I think Thomas is not indicating a bug, but rather 
enquiring about additional functionality. 

What I think both Thomas and I are interested in achieving is as follows. 
Let's say we have a tree like below. Note that all nodes are NOT clones 
unless specifically stated:

Node A
 + Node A1
 + Node A2
 + Node A3
Node B
 + Node A1 (a clone)
 + Node B2
   + Node A3 (a clone)


Now, what I want to do is copy Node B and have the following result:

Node A
 + Node A1
 + Node A2
 + Node A3
Node B
 + Node A1 (a clone)
 + Node B2
   + Node A3 (a clone)
Node B (but this is a copy, not a clone)
 + Node A1 (still a clone)
 + Node B2 (but this is a copy, not a clone)
   + Node A3 (still a clone)

I would love this functionality, but currently it's not present. I think 
there are many use cases for this. I use it for templating-like tasks. But 
at the moment it's really clunky to achieve, as I have to use Paste-node 
then reinstate the clones. I often miss some and then chaos ensues.


-- 
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 leo-editor+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/2f77daee-df18-4680-9a17-8d1c763f4bdf%40googlegroups.com.

Re: On the Semantics of Copying Clones

[Edward K. Ream]

On Fri, May 22, 2020 at 1:06 PM Thomas Passin  wrote:

This sounds as if a cloned node in the original tree will end up as a
> cloned node in the final tree.  That is not what I see, though.  The node
> that is a clone in the original tree  becomes a copy (not a clone) in the
> pasted tree.  That would fit in with "new gnx's for all pasted nodes".
>

You misunderstand me. If there are two (cloned nodes) A in the copied tree,
those clones will be clones *of each other* in any pasted tree, as I have
just verified.

It's harder to describe what happens than to verify what happens. I'm quite
sure Leo does the correct thing in all situations.

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 leo-editor+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/CAMF8tS0q6zzNCzUK5buEWVgbk1oqC23eTNk7FLhr2QjSoBAxXA%40mail.gmail.com.

Re: On the Semantics of Copying Clones

[Thomas Passin]

On Friday, May 22, 2020 at 11:08:19 AM UTC-4, Edward K. Ream wrote:

> On Wed, May 20, 2020 at 9:06 AM Thomas Passin  > wrote:
>
>> What should happen when I copy a tree that contains a clone?  
>>
>
> Leo copies the tree to the clipboard as is, that is, *retaining *gnx's. 
> What happens next depends on how you *paste* the tree:
>
> - The paste-node (Ctrl-Shift-v), command allocates *new* gnx's for all 
> pasted nodes.
> - The paste-retaining-clones command (Paste Node As Clone, from the 
> Outline menu), retains the gnx's for all pasted nodes.
>
> Either way, if the pasted tree contains clones (nodes with more than one 
> link to them in the pasted tree) then those nodes will be cloned after the 
> paste.
>

This sounds as if a cloned node in the original tree will end up as a 
cloned node in the final tree.  That is not what I see, though.  The node 
that is a clone in the original tree  becomes a copy (not a clone) in the 
pasted tree.  That would fit in with "new gnx's for all pasted nodes".

I don't want to clone the entire tree, because the whole point is to modify 
the original while keeping most of it as is.  For example, I might add some 
imports, or make some new constant assignments.  I don't want to end up 
with two import nodes (one the cloned one and one for new imports) or two 
Declaration nodes just so I can add lines to the skeleton of the original.

It's not a big issue for me but I expected that a cloned node in the 
original would end up still being a clone in the copy.  If that was the 
intent, then there is a bug.  If it was not the intent, well, OK.

-- 
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 leo-editor+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/4fcf901b-5f0e-4098-9add-91f32d237f4e%40googlegroups.com.

Re: On the Semantics of Copying Clones

[Edward K. Ream]

On Wed, May 20, 2020 at 9:06 AM Thomas Passin  wrote:

What should happen when I copy a tree that contains a clone?
>

Leo copies the tree to the clipboard as is, that is, *retaining *gnx's.
What happens next depends on how you *paste* the tree:

- The paste-node (Ctrl-Shift-v), command allocates *new* gnx's for all
pasted nodes.
- The paste-retaining-clones command (Paste Node As Clone, from the Outline
menu), retains the gnx's for all pasted nodes.

Either way, if the pasted tree contains clones (nodes with more than one
link to them in the pasted tree) then those nodes will be cloned after the
paste.

Finally, after a paste-retaining-clones, Leo might create new cloned nodes
if the gnx of a node outside the pasted tree matches the gnx of a pasted
node.

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 leo-editor+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/CAMF8tS23kMJ8Fj8ScOLx%2BeH2%2BXJLycYSV1y04J-iFSPiRHMy6g%40mail.gmail.com.

On the Semantics of Copying Clones

[Thomas Passin]

I have a series of little @file programs, all in the same outline,  that 
use a skeleton that is nearly the same.  For each new one, I copy the 
skeleton and then modify it.  One or more of the nodes, however, are always 
the same.  I clone that node, so that if I make an changes or fixes, all 
the programs get the changes to that node.

What should happen when I copy a tree that contains a clone?  I assumed 
that the new tree would contain yet another clone of that node.  But what I 
actually get is a copy of the original node, not a clone.  I deal with this 
by cloning the desired node, then deleting the unwanted copy.

What is the intended behavior when a tree containing a cloned node is 
copied?  Should the clone be turned into a copy of its parent node, or 
another clone.  Personally, I think it should be another clone.

(Just for a little context, these programs are intended to be used as Unixy 
filters that act on X-Y data that is contained in two-column text files 
that may contain comments or meta data.  A typical use might be like this:

type datafile | timeshift -s 5 | scale -s 11.5 | diff | smooth -w 10 | plot

(This is for Windows - for Linux, of course, you would cat datafile instead). 
Since they all read the same kind of data from stdin, write the same data 
format to stdout, read similar command line options, etc, the skeletons are 
nearly but not exactly the same.  However, the code that turns the text 
data into numbers is always the same - it has to be or the pipeline 
components wouldn't work together.

-- 
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 leo-editor+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/7fbd352e-12e1-4bca-a01e-7a04a429d514%40googlegroups.com.