date:20200527

On Wednesday, May 27, 2020 at 12:15:38 PM UTC-4, Edward K. Ream wrote:
>
>
> On Wed, May 27, 2020 at 10:44 AM vitalije > 
> wrote:
>
>> I would only suggest to leave out settings file from the proposal.
>>
>
> Sounds reasonable. If people want "global" settings that can be added 
> later.
>
> Hmm. If all templates are local, there is less need for 
> prompt-for-template...
>

I'm liking this proposal.  My (limited) experience with writing commands is 
that at first, I only expect to use them within the one outline file I'm 
working on. The commands and shortcuts would live in the settings tree of 
that outline. Later, I may find I want to use them with other outlines.  At 
that time, I would copy my command and shortcut nodes to 
MyLeoSettings.leo.So I wouldn't object to expecting a template to exist 
within a settings tree.  It could be local or global depending on what 
outline it was in.

I'm agnostic as to whether an @template tree could also be outside of a 
@settings tree.  But if it were outside, and the machinery already had been 
written that expects it to be in a @settings tree, then I think the extra 
effort to also process it somewhere else would not be needed.

-- 
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/9cc24e4b-b64b-4d09-882f-65e55411187a%40googlegroups.com.

Re: On the Semantics of Copying Clones

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: Proposal: @template nodes and related commands

On Wed, May 27, 2020 at 10:44 AM vitalije  wrote:

> I would only suggest to leave out settings file from the proposal.
>

Sounds reasonable. If people want "global" settings that can be added later.

Hmm. If all templates are local, there is less need for
prompt-for-template...

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/CAMF8tS0E69%2BuS4dV1UMvZNLHrL7fDu712KPP_UQ6gESr8BAAcA%40mail.gmail.com.

Re: Proposal: @template nodes and related commands

I would only suggest to leave out settings file from the proposal.

It doesn't add anything substantial and it might lead to worse user 
experience (having to open settings file to change something, then save it 
and then restart Leo or reload settings).

Instead command can look in the current outline for the @templates node and 
work the same way as you proposed. This won't require any change to the 
configParser and config classes and user would be free to change template 
and immediately see the effects. 

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/655b8fe8-c062-4900-94ef-f19c74338769%40googlegroups.com.

Re: Proposal: @template nodes and related commands

On Wednesday, May 27, 2020 at 9:32:41 AM UTC-5, Edward K. Ream wrote:

There are several details about the proposal which I forgot to mention:

*Writing the template*

Writing the template is the tricky part. The write code will allocate new 
gnx's to all nodes that are *not* descendants of candidate clones.

If a node *is* a descendant of a candidate clone, then that node's gnx 
absolutely must not change! All clones (of the same node) are actually the 
same vnode. It makes no sense to have the children of "one" clone be 
different from the children of the "other" clone. Do you see?

*Using the clipboard is optional*

The benign "s" kwarg allows c.outlineCommands.pasteOutlineRetainingClones 
to get its input from a string instead of the clipboard. Therefore, the 
write code can might optionally write to a string rather than the 
clipboard. Otoh, writing to the clipboard may be better. I don't care much 
either way.

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/cf833dd7-f470-406f-bae5-e7dcc7d61b66%40googlegroups.com.

Proposal: @template nodes and related commands

This proposal incorporates ideas from the "Semantics of coping clones"
thread. Imo, this proposal solves all the problems that have been
discussed, with additional benefits.

*Motivating ideas*

1. We want one or more *indivisible* (atomic) operations that copy a
template and paste it following c.p. Because the operations are atomic,
they will work as expected when done twice.

2. We want a flexible, general way of indicating which nodes are candidates
for being clones after the paste.

3. We want to refer *by name* to templates defined in myLeoSettings.leo or
leoSettings.leo.

*@templates and @template nodes*

Leo will support @templates and @template nodes in @settings trees. Only
one @templates node should exist in an @setting tree.

Each @template node should be a direct child of the single @templates node.
Each @template node will specify a *template name*, like @template
django-template. The template consists of *all* the descendants of the
@template node. A template can contain multiple nodes.

*Template-related commands and methods*

The *prompt-for-template* command will enter the minibuffer and aks the
user for the name of a template. Tab completion will show the existing
template names.

The *c.insertTemplateByName*(template_name) and *c.insertTemplate*(p)
methods will make it easy to insert templates using @button or @command
nodes.

All these commands and methods will be atomic: they will find a template,
copy it to the clipboard, and then do paste-retaining clones.

*Handling clones*

All cloned nodes in the children of an @template tree become* candidate
clones*. They will actually become clones if the paste-retaining-clones
makes them clones.

Now we can see why the @templates node exists. It provides a convenient
place to define clones *outside *of any @template (singular) node. In
effect, these *external clones* mark nodes *inside* @template nodes as
being candidate clones. There is no need to use marks.

*Note*: If the gnx of a cloned node in a template matches the gnx of any
node in the file receiving the template, then the template node *will*
become a clone after, say, c.insertTemplateByName. The user can "transfer"
gnxs to templates in myLeoSettings.leo using paste-retaining-clones.

*Summary*

The scheme proposed here is more general and flexible than those discussed
so far. It will require straightforward extensions of Leo's existing
settings machinery. There is no need for an alternate version of
paste-retaining-clones.

I encourage all questions and comments :-)

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/bb3d249f-961c-430f-abe7-74c92ab54ad1%40googlegroups.com.

Re: On the Semantics of Copying Clones

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

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



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



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

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

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

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

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

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

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

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

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

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

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

2020-05-27 Thread 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

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

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



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



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

@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

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

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

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

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

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

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

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

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

2020-05-27 Thread 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