"Unbreakable UNLs" Can Break Under A Common Scenario

[Thomas Passin]

I think it's not uncommon to cut a node and paste it somewhere else in the outline.  For example, if I want to move a node from near the top to near the bottom of a long outline, it would be impractical to move it down node by node or to drag it.  I simply cut and paste it.

Trouble is, when you cut a node and paste it, its gnx changes.  To prevent that you would have to remember to paste the node as a clone rather than do a simple paste.  This is asking for trouble. (And it's a weakness of my zettel-kasten system, which is gnx-based).

It's true that legacy path-based UNLs have the same problem.  But at least that's fairly obvious, whereas the new gnx-based UNLs are supposed to be unbreakable.

I don't have a ready solution to offer at this point, but I think it's a real scenario.

[Thomas Passin]

Maybe a paste of a node should always maintain the gnx unless it would create a clone.

[Edward K. Ream]

On Thu, Jul 6, 2023 at 6:40 AM Thomas Passin <tbp1...@gmail.com> wrote:

Maybe a paste of a node should always maintain the gnx unless it would create a clone.

Hmm. Under what circumstance would a paste-node not create a clone?

I sometimes use paste-node to create an independent copy of a node (and its descendants). It's a way of cherry-picking a node from one branch to another:

- Copy and paste a node N in branch A to a copy of N, say N-Copy.

- Close Leo, change to branch B.  Never leave Leo open when changing branches.

- Open Leo. Now we're in branch B, but N-Copy contains the cherry-picked node from branch A.

- Copy the body text of nodes from N-Copy to N. This changes N's text while preserving N's gnx.

Edward

[Thomas Passin]

Here's what I tried in my workbook:

1. Create a node for testing.

2. Copy its gnx to clipboard using a tiny script. *

3. Paste that gnx into the node's body for future reference.

4. Cut the node using the Outline/cut-node item.

5. Paste the node somewhere else in the same outline.

6. Copy the node's gnx to the clipboard.

7. Paste the gnx into the node's body.

8. Observe the 2nd gnx is not the same as the first.

* If you are having the statusbar show the gnx form of the unl, you can of course copy that from the clipboard instead of using a little script.

A screenshot of the test node is attached.

[Edward K. Ream]

On Wed, Jul 5, 2023 at 11:21 PM Thomas Passin <tbp1...@gmail.com> wrote:

Trouble is, when you cut a node and paste it, its gnx changes.  To prevent that you would have to remember to paste the node as a clone rather than do a simple paste.  This is asking for trouble. (And it's a weakness of my zettel-kasten system, which is gnx-based).

Then don't move nodes by cut and paste!

I never move nodes this way. Surely you can find an alternative that works for you.

Edward

[Edward K. Ream]

On Thu, Jul 6, 2023 at 7:42 AM Thomas Passin <tbp1...@gmail.com> wrote:

Here's what I tried in my workbook:

1. Create a node for testing.

2. Copy its gnx to clipboard using a tiny script. *

3. Paste that gnx into the node's body for future reference.

4. Cut the node using the Outline/cut-node item.

5. Paste the node somewhere else in the same outline.

6. Copy the node's gnx to the clipboard.

7. Paste the gnx into the node's body.

8. Observe the 2nd gnx is not the same as the first.

As expected.

Edward

[Thomas Passin]

The gnx change  may be expected, but as a user if I cut a node and paste it somewhere else, in my mind it's the *same* node and an "unbreakable" UNL should take me to that same node afterwards.  In my mind there should be no difference between moving a node using move commands (like CTRL-D) and moving it by cut-paste.  

I would say that a user who has not thought about, or maybe not even learned about, gnx's would not expect a unl to break when he did a cut-paste on a node.  

[jkn]

On Thursday, July 6, 2023 at 1:45:21 PM UTC+1 Edward K. Ream wrote:

On Wed, Jul 5, 2023 at 11:21 PM Thomas Passin <tbp1...@gmail.com> wrote:

Trouble is, when you cut a node and paste it, its gnx changes.  To prevent that you would have to remember to paste the node as a clone rather than do a simple paste.  This is asking for trouble. (And it's a weakness of my zettel-kasten system, which is gnx-based).

Then don't move nodes by cut and paste!

really?!

What are Outline | Cut-Node and Outline | Paste-Node for then?

[Edward K. Ream]

On Thursday, July 6, 2023 at 7:45:21 AM UTC-5 Edward K. Ream wrote:

Then don't move nodes by cut and paste! I never move nodes this way.

Devs should never move a node by cut/paste!!

Doing so destroys the node's gnx. In effect, the dev is claiming that they created the node, not the original creator!

Changing the identify of the node will also thwart Leo's upcoming git-history feature. See #3423.

Btw, new unls make clear who created the node. Or who pasted it last, hehe.

Edward

[Edward K. Ream]

On Thursday, July 6, 2023 at 8:11:56 AM UTC-5 jkn wrote:

What are Outline | Cut-Node and Outline | Paste-Node for then?

An earlier reply (in this thread) explains that "copy outline" creates an independent copy.

Useful for cherry-picking nodes from other branches.

A later reply (in this thread) explains why Leo devs should never move nodes by copy/paste.

Edward

[Thomas Passin]

Hmm, we have a real disagreement here.  I think that cut-paste within an outline should be equivalent to a move.  And anyway, some fundamental property like node identity should not have to depend on whether someone happens to remember a subtle point - if they even had learned about it - when their mind is thinking of something else.

[jkn]

Hi Edward

  By  'devs', do you mean, erm ... 'users' ?

I agree with Thomas, I think there is a real disagreement here.

Has it always been true that "Leo devs should never move nodes by copy/paste", or is this a recent ... limitation, or ... evolution of your thinking, or what?

    Thanks, Jon N

[Edward K. Ream]

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

Hmm, we have a real disagreement here.  I think that cut-paste within an outline should be equivalent to a move.  And anyway, some fundamental property like node identity should not have to depend on whether someone happens to remember a subtle point - if they even had learned about it - when their mind is thinking of something else.

I'm glad the issue has come to the fore.

This is not a matter of opinion. No option can mitigate the evil effects of copy/paste.

I don't care if you change gnxs in VR3, but you must not gnxs anywhere else.

Edward

[Edward K. Ream]

On Thu, Jul 6, 2023 at 8:28 AM jkn <jkn...@nicorp.f9.co.uk> wrote:

 By  'devs', do you mean, erm ... 'users' ?

I meant anyone who commits code to Leo's code base.

The harmful effects of copy-node/paste-node would also apply to other devs, that is, anyone who commits code to any other code base.

Edward

[Edward K. Ream]

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

The gnx change  may be expected, but as a user if I cut a node and paste it somewhere else, in my mind it's the *same* node and an "unbreakable" UNL should take me to that same node afterwards.  In my mind there should be no difference between moving a node using move commands (like CTRL-D) and moving it by cut-paste.  

I would say that a user who has not thought about, or maybe not even learned about, gnx's would not expect a unl to break when he did a cut-paste on a node.

The average Leonista may cut and paste nodes without harm. Leo's devs must never do so.

Clear?

Edward

[Jacob Peck]

I move nodes like this all the time.  Additionally, I rarely ever use clones, despite being one of Leo's 'headline features'.

Your recent prescriptivism has been a bit frustrating as someone who has been using Leo for over a decade.  The joy of Leo is that the user can do things in so many ways.  I sincerely think that imposing these 'hidden'* restrictions on user activity is an objectively bad move.

To be clear, I love Leo, and I genuinely appreciate all the design and work that has gone into it.  I just think perhaps we're moving fast and breaking things just to do so, lately.  It's frustrating and difficult to keep up with.  And I say this as someone who has developed a handful of plugins in the repo, was involved in the bzr->git migration, and contributed a fair amount of bugfixes over the years.

(*I say 'hidden' because how is a user unfamiliar with Leo's internals supposed to grok that cut-paste to move a node, an extremely common method of moving data in other applications, will have unintended, internal consequences?  This is just *bad* UX, full stop.  The user shouldn't have to think about the internal data structure of the thing they're working on.)

Just my $0.02.  Please take this as constructive -- I believe we all want Leo to be the best it can be.

Jake

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

[jkn]

So, "once you have learned about gnx's, Cut- and paste- nodes is lost to you"?

Sorry, like Jake says, I am trying to be constructive here. But I too think things are moving too fast.

Jon N

[Edward K. Ream]

On Thu, Jul 6, 2023 at 8:49 AM Jacob Peck <gates...@gmail.com> wrote:

Your recent prescriptivism has been a bit frustrating as someone who has been using Leo for over a decade.

You can do anything you like provided you don't issue a PR.

Edward

[Edward K. Ream]

On Thu, Jul 6, 2023 at 9:28 AM jkn wrote:

> So, "once you have learned about gnx's, Cut- and paste- nodes is lost to you"?

Not at all. Only Leo's devs need to take care.

To repeat: a Leo dev is someone who changes Leo's codebase.

And I don't mind if Leo devs change gnxs in their own plugins.

> I too think things are moving too fast.

Yes. I get that :-) But everyone can calm down:

- Nothing is likely to break.

- I'll fix anything that does break.

- There are no new rules (unless you are a Leo dev).

I don't mind answering these questions. It's part of the process of changing Leo.

Edward

[Thomas Passin]

On Thursday, July 6, 2023 at 11:36:41 AM UTC-4 Edward K. Ream wrote:

On Thu, Jul 6, 2023 at 9:28 AM jkn wrote:

> So, "once you have learned about gnx's, Cut- and paste- nodes is lost to you"?

Not at all. Only Leo's devs need to take care.

To repeat: a Leo dev is someone who changes Leo's codebase.

Anyone who uses a UNL to point to a node can get bit by this, not only Leo codebase devs. 

Consider this scenario:  A user clones node N at position P1 and moves the clone to position P2.  This node and its clone have gnx1. Then he deletes P1.  The node at (what used to be) P2 now has gnx1.

OTOH, if the user cuts node N at Position P1 and then pastes it into position P2, then the node at P2 will have a different gnx, say gnx2. gnx2 != gnx1.

Any normal person would think that these operations will end up with the same result.  I don't see any reason why there should be non-intuitive behavior in this scenario.  Of course it only matters if those gnxs get used for something.  The most likely way they would get used by a normal user - or even a non-Leo-codebase script developer - would be for new-style unls.

I have this problem - that I have to remember to paste as a clone - with my zettel-kasten system and its adaptation to family history/geneological data.  That's because I use gnxs to crosslink everything.  At least I knew this (use clone rather than plain paste) would be a problem almost from the beginning but it's taken discipline on my part to avoid wrecking the data structures.  I almost created my own ID system but gnxs were easier to use and persist, so I went with them.

I propose that whether a node gets cut or copied, that:

1. If it gets pasted into the same outline, then it should keep the original gnx *unless* that gnx already exists in the outline.  Then the pasted copy should get a new gnx;

2. If a node is copied and pasted into a different outline, then again it should keep its gnx unless a node with that gnx already exists;

3. Paste-as-clone should always keep the original gnx.

This would make the behavior as intuitive as possible.

[Edward K. Ream]

On Thu, Jul 6, 2023 at 11:09 AM Thomas Passin <tbp1...@gmail.com> wrote:

I propose that whether a node gets cut or copied, that [snip].

Many thanks for this great idea.

See #3429. I'll do this asap.

Edward

[jkn]

Thomas' list sounds pretty sensible to me at first blush. Nevertheless, I do wonder whether keeping things in a discussion/proposal phase for a while would be a good idea, rather than (for instance) jumping onto #3429.

    J^n

[Edward K. Ream]

On Thu, Jul 6, 2023 at 2:09 PM jkn <jkn...@nicorp.f9.co.uk> wrote:

Thomas' list sounds pretty sensible to me at first blush. Nevertheless, I do wonder whether keeping things in a discussion/proposal phase for a while would be a good idea, rather than (for instance) jumping onto #3429.

Why wait :)

Edward