If I'm understanding correctly, with your planned changes if a user opens a leo file and makes a few changes and then undoes all the changes and tries to close the file, then the user will be prompted about saving changes even though the outline matches everything on disk. Is that correct?
That behavior doesn't seem to be the most user friendly. Better that than having the bug where changes are lost, but I wonder if there is a way to have both without it being too complicated? Just thinking out loud, but maybe it would work to have a dirty counters for the nodes. After a save, all the dirty counters are reset to zero. Undo operations decrement the dirty counter for affected nodes and redo operations increment the counter. Any time a given node's counter is at zero, the dirty bit is cleared and any time the counter is non-zero, the bit is lit. On Sat, Dec 14, 2019 at 11:31 AM Edward K. Ream <[email protected]> wrote: > The complexity of the undo code has collapsed. This is a most welcome > milestone: > > - All the dirtyVnodeList kwargs and associated logic are gone. This is > big. > > The undo/redo code now just calls p.setDirty one or more times. This works > because p.setDirty now calls v.setAllAncestorAtFileNodesDirty. This is > feasible because Vitalije's code is super fast, and because it uses vnodes, > not positions. > > When moving node.p, the pattern is: > > p.setDirty() > << do the move >> > p.setDirty() > > The point is that moving a node may change its parents, so both calls to > p.setDirty are necessary. > > This is surely the simplest thing that could possibly work. However, I am > tempted to have the low-level VNode methods call > v.setAllAncestorAtFileNodesDirty "automagically". This is feasible now > that marking nodes dirty happens in the vnode world, not the position > world. However, I probably *won't* go that far: the low-level vnode > methods probably don't have enough context to do the right thing reliably. > > - v.setAllAncestorAtFileNodesDirty no longer returns a dirtyVnodeList, so > I was able to collapse the complexity of that method as well. > > I have thoroughly reviewed all aspects of the undo code. However, more > simplifications may be possible, and a few arcane questions remain. It's > possible that those questions represent edge cases that could cause bugs. > I expect to work on this issue for a day or two more. > > 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/2874489c-defe-4bdf-90a9-b2c6639858ef%40googlegroups.com > <https://groups.google.com/d/msgid/leo-editor/2874489c-defe-4bdf-90a9-b2c6639858ef%40googlegroups.com?utm_medium=email&utm_source=footer> > . > -- 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/CAO5X8CxzOWVQ2Tq5C4T_-ex-7G%2B5Oxj0qU2pJOp9aLzoMoo0UA%40mail.gmail.com.
