> > On second thought, I'm not willing to consider such a scheme. The present > scheme preserves all aspects of v, including editing position, uA, and > anything else that, say, a plugin might add. > > The references ensure the that GC will never delete the vnode. This is > exactly what I intend. > > Not that I insist on anything but both of this two arguments are irrelevant. The reference of vnode exists in the children and parents lists so there is no need to keep another one to prevent GC. And undo/redo machinery doesn't take into account uAs at all. So if a plugin wishes to make some uA attribute change undoable it has to implement its own undo/redo. Therefore nothing important is gained by keeping the vnode reference in the undo stack.
You may say nothing important will be gained by keeping (gnx, h, b, gnxchildren, gnxparents) instead of vnodes. It might even seem a little more work to do. But on the other hand the mutability of undo data is a potential source of hard to find bugs. On several places in Leo's code c.fileCommands.gnxDict is changed. If a vnode with the same gnx is ever created after one has been stored in the undo stack, we would have an invalid situation of two different instances with the same gnx. By the way, #1541 is done at ba21c2f2 <https://github.com/leo-editor/leo-editor/commit/ba21c2f27d463675c3b728390a3c2c396e52736e>. And I did it storing only gnx-es and ints. The deletePositionsInList now returns undo data, and c.undoableDeletePositions uses this data to make operation undoable. Vitalije -- 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/d63f76b0-49f0-4cb1-9082-e2b76369cdd9%40googlegroups.com.
