Changes impacting undo/redo

[SegundoBob]

Between 2019-10-06 and 2019-12-24, several changes were made that impact undo/redo.

1. The setDescendentsDirty argument was dropped from pos.setDirty() and vnode.setDirty().
2. Method pos.setAllAncestorAtFileNodesDirty() was changed to return None instead of a list of all the nodes set dirty.

I changed some of my code to accommodate change 1.  But before I figure out how to accommodate change 2, I would like reassurance that this change is desirable.

To implement undo/redo my code contains these lines.

undoer.afterMoveNode(posTargNew, undoType, undoData, dirtyVnodeList)

undoer.afterChangeGroup(posTargNew, undoGroupType, reportFlag=False, dirtyVnodeList=dirtyVnodeList)

Why is the "dirty dirty vnode list" no longer needed by undoer.afterMoveNode() and undoer.afterChangeGroup()?

Thanks to whoever answers,

SegundoBob

[Edward K. Ream]

On Thu, Dec 26, 2019 at 7:23 PM SegundoBob <segun...@gmail.com> wrote:

> Why is the "dirty dirty vnode list" no longer needed by undoer.afterMoveNode() and undoer.afterChangeGroup()?

This list is no longer used anywhere. The old undo logic used this list to restore dirty bits after an undo/redo operation.  But this is severely misguided because saving a file clears all dirty bits.

Rather than add still more complexity to account for saves, it's much simpler and safer to "declare" that all undo/redo operations mark their respective nodes as dirty.  In the new code, p.dirty() also marks all ancestor @<file> nodes as dirty.

Rest assured that the dirtyVnodeLists are not coming back.

Edward

[Segundo Bob]

Excellent. Thanks.

--
Segundo Bob
Segun...@gmail.com