Leo file dirty state.

[Félix]

Testing Leo to compare with leointeg  (and leojs) I stumbled upon a little something I 'd like to inquire about: 

When using ctrl+shift q and/or ctrl+w to write @<files> without necessarily saveing the .leo file itself, I found out that if this operation makes ll positions non-dirty, then the whole file is considered non-dirty. 

(even if a node, outside of an @file,  was deleted, making the file dirty, making all other nodes non-dirty by hitting ctrl+shift+q makes the whole file non-dirty.)

To make it clearer try this: 

1-make an @file with a child, dirty the body of the child, hit ctrl+shift+q. all clean, ok. normal so far...

2-Now make a couple of nodes outside the @file subtree, dirty one, delete it. (no dirty nodes but file still dirty.) dirty an @file child's body, (nodes and file now dirty) hit ctrl+shift+q. 

3- Assert that all nodes are non-dirty but now the whole file is also considered non-dirty even though a node was deleted, changing the .Leo document structure... but this deletion will be lost if closing Leo.

--

Félix

[Félix]

in 2nd paragraph, "makes ll positions " should read "makes all positions" 

[Edward K. Ream]

On Tue, Nov 16, 2021 at 7:26 PM Félix <felix...@gmail.com> wrote:

When using ctrl+shift q and/or ctrl+w to write @<files> without necessarily saveing the .leo file itself, I found out that if this operation makes [all] positions non-dirty, then the whole file is considered non-dirty.

Sounds like a problem. I'll take a look.

Edward

[Edward K. Ream]

On Tue, Nov 16, 2021 at 7:26 PM Félix <felix...@gmail.com> wrote:

Testing Leo to compare with leointeg  (and leojs) I stumbled upon a little something I 'd like to inquire about: 

When using ctrl+shift q and/or ctrl+w to write @<files> without necessarily saveing the .leo file itself, I found out that if this operation makes all positions non-dirty, then the whole file is considered non-dirty. 

(even if a node, outside of an @file,  was deleted, making the file dirty, making all other nodes non-dirty by hitting ctrl+shift+q makes the whole file non-dirty.)

I'm having trouble following this.

To make it clearer try this: 

1-make an @file with a child, dirty the body of the child, hit ctrl+shift+q. all clean, ok. normal so far...

Right.

2-Now make a couple of nodes outside the @file subtree, dirty one, delete it. (no dirty nodes but file still dirty.) dirty an @file child's body, (nodes and file now dirty) hit ctrl+shift+q. 

Huh?  What do you mean, "make a couple of nodes outside the @file subtree".  How can that affect the status of the external file?  Are you talking about cloned nodes?

3- Assert that all nodes are non-dirty but now the whole file is also considered non-dirty even though a node was deleted, changing the .Leo document structure... but this deletion will be lost if closing Leo.

 

I do see a potential problem, but it could only happen if two @file trees contain clones of the same node, say node N.

at.writeAllHelper contains this code:

    # Clear the dirty bits in all descendant nodes.
    # The persistence data may still have to be written.
    for p2 in p.self_and_subtree(copy=False):
        p2.v.clearDirty()

This will clear the dirty bits of node N in both files, but will not affect the status of only one of the @file nodes, namely node p in the code above.

Let's look at at.writeOneAtFileNode. It does not appear to change the dirty status of any node.

Let's look at c.deleteOutline, in leo/commands/commanderOutlineCommands.py. The relevant code is:

    undoData = u.beforeDeleteNode(p)
    p.setDirty()
    p.doDelete(newNode)
    c.setChanged()
    u.afterDeleteNode(newNode, op_name, undoData)

This looks correct.  p.setDirty() dirties all ancestor @file nodes before deleting p itself.

In short, I don't see a big problem. Do you?

Edward

[Félix]

Sorry - english is not my first language so perhaps my proposed experiments steps are not well defined or clear enough...

>Huh?  What do you mean, "make a couple of nodes outside the @file subtree".  How can that affect the status of the external file?

  How can it affect the status of the external file? Well you are right, it doesn't! But that's not a bug about the dirty state of the @file nor its nodes, nor its derived external file...  it's about the dirty state of the whole Leo document. (Closing Leo with a dirty Leo Document will trigger the 'are you sure' dialog to prevent body or tree-structure loss... That does not happen with the experiment I'm proposing) 

 And so, at step 2, I mean exactly what I wrote: make a (one or many) node 'outside' the @file subtree. either above or below... and then dirty one of them by typing in its body pane. And then delete it. (whole document considered dirty at this point with the asterisk in the tab name) ...Then, dirty a node 'inside' the @file subtree. And hit ctrl+shift+q. and at that point, the bug will be staring you in the face. 

Hope this makes it apparent :)  Too lazy to record my screen for an animated gif tonight!

--

Félix

[Edward K. Ream]

On Wed, Nov 17, 2021 at 7:14 PM Félix <felix...@gmail.com> wrote:

>Huh?  What do you mean, "make a couple of nodes outside the @file subtree".  How can that affect the status of the external file?

[This is not] a bug about the dirty state of the @file nor its nodes, nor its derived external file...  it's about the dirty state of the whole Leo document.

Oh.  I see. Thanks.

Edward