This is an Engineering Notebook post discussing
#1451: @clean and @auto may not always be updated reliably.
Background
Whenever an outline changes, Leo must remember that any @<file> node affected by the change should be written when the outline is next saved. Leo does this by marking all such @<file> nodes dirty.
p.setAllAncestorAtFileNodesDirty finds all @<file> nodes that contain a changed node p. This method has changed relatively recently. The new code is much faster than before, and I believe the new code is correct. However, both the old and new code return a list of vnodes that have newly become dirty as the result of p's becoming dirty. It may be better just to return a list of all @<file> nodes that contain p. (If so, the name should change).
In the past (say last year) p.setAllAncestorAtFileNodesDirty also set descendant @<file> nodes dirty. This happened by default, but could be disabled via a kwarg. There was some reason for doing this. Leo directives in an ancestor node might affect, say, the language in effect for descendant nodes.
It is still debatable whether setting descendant @<file> node dirty is a good idea. At present, I don't think it's necessary. However, the old way might have masked this bug.
The source of the bug
At present, the undo code remembers which nodes (vnodes) were dirty when the undoable operation happened. Undo/redo then saves/restores those saved nodes. But this is subtly wrong, because saving a file clears all dirty bits.
The fixes:
1. The undo/redo code should always marked the entire outline as changed. In no event should any undo/redo operation clear the outline's changed
bit.
2. The undo/redo code should no longer remember which nodes were dirty when the undoable operation first happens (or was redone). Instead, all undo/redo helpers should return a list of vnodes affected by the undo/redo. Details omitted. The top-level undo/redo methods will then ensure that all ancestor @<file> nodes of all the affected nodes are marked dirty.
Summary
This bug likely arises because saving a file changes data cached by the undo code.
This bug may have been around for a long time. This bug likely affects all kinds of external file, not just those created by @auto and @clean.
The fix should be straightforward: compute the needed data from first principles whenever undoing or redoing an operation. This will simplify the code by eliminating cached data.
p.setAllAncestorAtFileNodesDirty is likely innocent. However, it may be renamed and repurposed.
Edward