On Tue, Nov 16, 2021 at 7:26 PM Félix <[email protected]> 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
--
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 [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/leo-editor/CAMF8tS1t523rFQ4v-iT1BqB%2BSEiv4o%2B79-GUBBG52h%2BSYL3j-A%40mail.gmail.com.
