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.
