The full title of the bug is: refresh from disk - cut node resurrection
https://bugs.launchpad.net/leo-editor/+bug/1090950
See the bug report for the original description. To summarize, refreshing
a file from disk (using the contextmenu plugin, or in *any* other way,
except by reverting the entire Leo outline) may cause the value of a
*previously deleted* node to be used instead of the value of that node in
the refreshed file.
Fixing this bug will have to wait until Leo 5.0. In fact, the fix for this
bug may lead to one of the defining features of Leo 5.0!
The problem is that Leo presently updates c.fileCommands.gnxDict only when
reading a file. But a fix for this bug would require that this dict be
updated (*carefully*) whenever nodes were cut, deleted, restored (via undo)
or re-cut or re-deleted (via redo). Errors in this "accounting" could
easily corrupt outlines. This is way beyond the scope of Leo 4.11.
A fix would not simply be some major behind-the-scenes complications.
Rather, it points the way to *safe* cross-file clones. Indeed, I envisage a
central **Leo Server**, operating whenever on the users machine whenever
any instance of Leo is open. This server would warn whenever two instances
of the same node (gnx) was open on two different instances of Leo.
Naturally, this server would also have a key role in Leo as web app.
Appendix
Here is detailed explanation why a "local" fix for this bug is impossible.
My first thought was that the bug could be fixed (in the refresh_rclick
function in contextmenu.py) by simply deleting all the children of the
to-be-refreshed node p using this helper::
def delete_children(p):
while p.hasChildren():
child = p.firstChild()
child.doDelete()
This would be called before re-reading the file. But this had no effect!
the resurrected value of nodes still reappeared. A little thought showed
why. All the atFile read code uses c.fileCommands.gnxDict to determine
whether a node (with a given gnx) has already been seen. If it has, then
the read code uses the already-read node instead of creating a new node.
This is essential in the "unified node" scheme Leo already uses.
My second thought was to clear the entries in the gnxDict entries for all
the nodes in the to-be-refreshed file. Something like::
for p2 in p.subtree():
gnx = p2.v.gnx
if gnx in c.fileCommands.gnxDict:
del c.fileCommands.gnxDict [gnx]
Again, this did not fix the bug. Doh! The bug resurrects a previously
*deleted* node, so the deleted node will not appear in p.subtree().
My final attempt was to delete c.fileCommands.gnxDict completely. But this
idea was doomed. Doing so would break any clone links from nodes in the
refreshed file to nodes in the outline. For example, the links to the A'
(cloned) nodes in::
+ A'
+ @file foo.py
+ A'
+ whatever
The inescapable conclusion: Leo will have to manage the gnxDict in the
fundamental code in leoNodes.py. This is a huge, very dangerous, change.
It is out of the question for any 4.x release.
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 post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/groups/opt_out.
