Aha: no need for a new paste command

[Edward K. Ream]

#3429 suggests that Leo's paste-node command should retain gnxs if doing so would create no gnx clashes in the pasted node.

Thomas, Félix and I have been debating what anyGnxClashes should check. Should it check the entire pasted tree or only its root? Depending on the answer, the paste-node will act like Leo's legacy paste-node or paste-node-retaining-clones commands.

Aha! The contents of the target outline don't matter! What matters is the user's intention.

Thomas uses cut-node/pastes-node mostly to move outlines. For him, paste-node-retaining-clones is likely the best binding for ctrl-shift-v.

But I typically use copy-node/paste-node to cherry-pick outlines from other branches. For me, paste-node is the best binding.

Summary

When using paste-node, the user won't know what anyGnxClashes will return. That can't be good!

Aha: it shouldn't matter what nodes are in the target outline. What matters is whether the user wants to regain gnxs!

Users who regularly use copy-node/paste to move nodes may find it best to bind ctrl-shift-v to paste-nodes-retaining-clones. Perhaps the binding for ctrl-shift-v should change in leoSettings.leo.

The work on this project has not been in vain. We all now understand more deeply how Leo's paste-node commands affect gnxs.

Please comment. I'll leave #3429 open while we continue our discussion.

Edward

[jkn]

I currently only see command paste-retaining-clones. Is this the command you are referring to (not paste-node-retaining-clones)?

I presume this is an older command (that I have not knowingly used).

I guess I am still ... nervous is not exactly the right word ... about having variants for what I think most users would see as a fundamental, and "trivial", operation. But I am trying to keep an open mind...

J^n

[Edward K. Ream]

On Fri, Jul 7, 2023 at 5:42 AM jkn <jkn...@nicorp.f9.co.uk> wrote:

I currently only see command paste-retaining-clones. Is this the command you are referring to (not paste-node-retaining-clones)?

Yes. I misspelled the name of the command.

Edward

[Edward K. Ream]

On Friday, July 7, 2023 at 3:59:49 AM UTC-5 Edward K. Ream wrote:

> I'll leave #3429 open while we continue our discussion.

I have assigned this issue to Leo 6.7.5. No way will this issue be part of 6.7.4.

Edward

[Thomas Passin]

I got some more clarity about this, and I commented the following on the proposed PR:

I can now see that the concept of operation is simple. Within an outline, for a parent-and-subtree:

• Ask for a move, get a move; gnxs do not change;
• Cut-paste is the same as a move;
• Ask for a copy, get a copy, meaning all nodes get new gnxs.
• To paste a copy when the top of the copied tree already exists means by definition to ask for a copy.

I think that Leo's defaults should act this way.  I'd rather that the behaviors not change via a setting because their effect can be invisible until later, when it might be too late.  Also, those of us who run several installations (for instance, on a Linux VM for testing purposes) would inevitably forget what state those settings were on what machine.  That might end up being very confusing, to say the least!

Once we're sure that the paste-copy and paste-clone commands are working as intended, then we can probably make it fairly clear by naming commands and menu items (and also in the docstrings) as to what to expect.

[Edward K. Ream]

On Friday, July 7, 2023 at 7:55:29 AM UTC-5 Thomas wrote:

I got some more clarity about this, and I commented the following on the proposed PR:

I can now see that the concept of operation is simple. Within an outline, for a parent-and-subtree:

• Ask for a move, get a move; gnxs do not change;
• Cut-paste is the same as a move;
• Ask for a copy, get a copy, meaning all nodes get new gnxs.
• To paste a copy when the top of the copied tree already exists means by definition to ask for a copy.

I think that Leo's defaults should act this way. 

I'm not going to do this. See the comments in the PR. I've closed this PR and am not likely to reopen it.

Edward

[Edward K. Ream]

On Friday, July 7, 2023 at 9:35:51 AM UTC-5 Edward K. Ream wrote:

> I'm not going to do this...I've closed this PR and am not likely to reopen it.

As always,  you can write a plugin that makes Leo work exactly as you want. You do not need my permission :-)  Note the preread code in the PR. It eliminates the need to override Leo's existing commands.

Edward

[Edward K. Ream]

On Fri, Jul 7, 2023 at 9:35 AM Edward K. Ream <edre...@gmail.com> wrote:

I'm not going to [do a state-oriented paste-node].

My apologies. I was too brusque.

Thomas, have you tried making paste-retaining-clones your default for ctrl-shift-v? I'm wondering whether you would encounter any problems.

Thanks.

Edward

[Thomas Passin]

No, I haven't tried it.  I'm not even sure I would want to.  

Think about how the Windows file explorer works.  If you copy a file and paste it, it gives the pasted file a name that includes "copy" if there is another file with that name in the same directory.   If there isn't another file in the target directory, the copied file gets pasted get the original, unmodified name.  File managers on linux work the same way.

I'm just saying that Leo ought to act the same way as the file managers where copying nodes are concerned.  It's the way way everyone's file manager already works, it's what one would expect, and it's not state-oriented unless you mean the state of whether or not there is an existing name

[Edward K. Ream]

On Sat, Jul 8, 2023 at 6:53 AM Thomas Passin <tbp1...@gmail.com> wrote:

No, I haven't tried it.  I'm not even sure I would want to.

I've asked several times, why not?

Think about how the Windows file explorer works.  If you copy a file and paste it, it gives the pasted file a name that includes "copy" if there is another file with that name in the same directory.

It's an interesting analogy but misleading. A Leo node is more like a directory than a file. Subnodes matter in this discussion.

The question is whether pastes should retain all gnxs or none of them.

Yes, Leo could copy a tree depending on whether clashes exist. But it's our intention that matters, not gnx clashes. That was the Aha.

Leo's paste-node and paste-retaining-clones commands support either intention. That should be enough.

Summary

It's easy to reject the proposal. It's unlikely to work as expected. Leo's existing commands suffice.

Edward

[Thomas Passin]

The discussion got me to examine the various commands' docstrings via F11.  paste-as-template was new to me, and might have been handy from time to time.  The word "template" doesn't convey anything useful to me about what the command does, but I don't have an alternate to suggest at this moment. The command name paste-retaining-clones is a little misleading to me because it leaves a question about what happens to non-cloned nodes in the copied subtree (they keep their gnxs too).  The menu item label (Paste Node As Clone doesn't quite match up with the command's name, at least to me.

I better write some clarifying text about these commands in the new user guide I'm slowly working on, I suppose.