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.

[Edward K. Ream]

On Wed, May 20, 2020 at 9:06 AM Thomas Passin <tbp1...@gmail.com> 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

[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 <tbp1...@gmail.com> 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.

[Edward K. Ream]

On Fri, May 22, 2020 at 1:06 PM Thomas Passin <tbp1...@gmail.com> 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

[John Clark]

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.

[Edward K. Ream]

On Sat, May 23, 2020 at 2:36 AM John Clark <leve...@theinsideworld.net> 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

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

[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

[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 <tbp1...@gmail.com> 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]

[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

[Mike Hodson]

On Tue, May 26, 2020 at 9:01 PM Edward K. Ream <edre...@gmail.com> 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

[John Clark]

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          # a copy
 + 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 between the source tree and the "copied" tree. Making copies of the local clones 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

Edit: Added comment to the copied Node Y to make it clear it was a copy

Edit 2: Important edit to last para to remove ambiguity

 

 

[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

[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

[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

[Edward K. Ream]

On Tue, May 26, 2020 at 10:09 PM Mike Hodson <mys...@gmail.com> 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

[Edward K. Ream]

On Wed, May 27, 2020 at 12:56 AM John Clark <leve...@theinsideworld.net> 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.

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

[Edward K. Ream]

On Wed, May 27, 2020 at 1:08 AM John Clark <leve...@theinsideworld.net> 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

[Edward K. Ream]

On Wed, May 27, 2020 at 2:08 AM vitalije <vita...@gmail.com> 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

[Edward K. Ream]

On Wed, May 27, 2020 at 4:56 AM Seth Johnson <seth.p....@gmail.com> 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

[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

[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

[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 <seth.p...@gmail.com> 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

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

[Seth Johnson]

On 5/27/20, Edward K. Ream <edre...@gmail.com> wrote:
> On Wed, May 27, 2020 at 12:56 AM John Clark <leve...@theinsideworld.net>

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

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

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

Hmmmmmmm

[Edward K. Ream]

On Wed, May 27, 2020 at 6:01 AM vitalije <vita...@gmail.com> 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

[Edward K. Ream]

On Wed, May 27, 2020 at 6:18 AM Thomas Passin <tbp1...@gmail.com> 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

[Edward K. Ream]

On Wed, May 27, 2020 at 6:17 AM Seth Johnson <seth.p....@gmail.com> 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

[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

[Seth Johnson]

On 5/27/20, vitalije <vita...@gmail.com> 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+...@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.
>

[Seth Johnson]

On 5/27/20, Edward K. Ream <edre...@gmail.com> wrote:

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+...@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.
>

[Edward K. Ream]

On Wed, May 27, 2020 at 6:34 AM vitalije <vita...@gmail.com> 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

[Seth Johnson]

On 5/27/20, Seth Johnson <seth.p....@gmail.com> wrote:
> On 5/27/20, vitalije <vita...@gmail.com> 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 :-) )

[vitalije]

On Wednesday, May 27, 2020 at 2:09:37 PM UTC+2, Differance wrote:

On 5/27/20, vitalije <vita...@gmail.com> 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

[Seth Johnson]

On 5/27/20, vitalije <vita...@gmail.com> wrote:
>
>
> On Wednesday, May 27, 2020 at 2:09:37 PM UTC+2, Differance wrote:
>>

>> On 5/27/20, vitalije <vita...@gmail.com <javascript:>> 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+...@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.
>

[vitalije]

On Wednesday, May 27, 2020 at 2:37:57 PM UTC+2, Differance wrote:

On 5/27/20, Seth Johnson <seth.p...@gmail.com> 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

[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

[Seth Johnson]

On 5/27/20, vitalije <vita...@gmail.com> wrote:
>

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+...@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.
>

[Seth Johnson]

On 5/27/20, Seth Johnson <seth.p....@gmail.com> wrote:

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.

[Thomas Passin]

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