I doubt this would be a very good idea. Undo/redo already has a lot of things to do. Adding some more chores to them will likely make things more complicated, slower and probably introduce more bugs.
Instead I suggest another approach. Please consider the rest of this message not as a critic of Leo's internals. I can't write any formal proof of the following claims, so consider them just as my personal feelings about Leo's position class. The way I see it, right now, positions are mixture of Model, View and Controller. Position methods are used to: 1. [Model] traverse the tree, retrieve the outline data 2. [View] represent outline nodes that can be viewed, clicked, double clicked, expanded or collapsed 3. [Controller] modify tree The fact that they are so involved in all three parts of MVC makes them vulnerable and unreliable not only because they can become invalid - that is just a part of the problem. There are a lot of other parts of Leo that can be simplified by avoiding usage of positions. In every piece of code I wrote in Leo, so far, I found that avoiding positions makes code shorter, cleaner and more robust. More than once I've found some method in Leo that was too complex or it contained a bug somewhere, and when I rewrote it without positions it became shorter, faster and more reliable. At least that is my experience with the Leo positions. There are even some places where one piece of code doesn't have a position but just a vnode, and in order to call some method that expects position one must first construct a dummy position containing the vnode, then call the other method which expects position, and inside this method uses p.v to do its job. Now, regarding the initial problem (I believe it was about expanded/collapsed state of nodes). Whichever GUI we can imagine that Leo will have in the future, and also in the Qt GUI at the present time, the GUI code will have the information about which visible nodes are expanded and which are collapsed. It is an essential bit of information required to show the outline. So, most natural place to hold this information is GUI code. If we put it somewhere else, we will have to deal with the synchronization between GUI and that other place. Some Leo commands for moving around the outline, selecting relative positions depend on this information (expanded/collapsed) but apart from that, expanded/collapsed state has no effect on the true meaning of the outline. External files will contain the same content regardless of whether their nodes were expanded or collapsed. So, we can consider this information as something inherently tied to the GUI or View part of MVC. The simplest possible solution will be just to delegate p.isExpanded method to the GUI and find corresponding tree item and ask it if it is expanded or not. For example: g.app.gui.isExpanded(p) # or c.frame.tree.isExpanded(p) # instead of p.isExpanded() IMHO the most natural place to store the expanded/collapsed bit about outline node is in the GUI/View. Also rethinking positions and their methods might be beneficial. My 2 cents. 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 leo-editor+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/leo-editor/43ba1540-646c-414e-a9e8-cf2f361a693eo%40googlegroups.com.
