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 On Wednesday, November 17, 2021 at 9:59:51 AM UTC-5 Edward K. Ream wrote: > 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/b6d7e1a3-3762-4054-aeb0-bb70acdd82b5n%40googlegroups.com.
