This Engineering Notebook post discusses possible fixes to #1437 <https://github.com/leo-editor/leo-editor/issues/1437>.
*Background* The *hidden *vnode is c.hiddenRootNode. The *root *vnode is c.rootPosition().v. My botched fix confused these two vnodes. I thank several people for checking my work. When creating any outline, Leo's startup code sets the *hidden *vnode, c.hiddenRootNode. This node itself never changes, but it's *contents *(v.children array) changes when top-level outline nodes are inserted or deleted. Leo's startup code give the hidden vnode a unique, invariant, gnx, namely 'hidden-root-vnode-gnx'. This gnx can never conflict with any other vnode in the outline. LeoFrame.createFirstTreeNode creates the *root *vnode. Leo will replace this root vnode by a *new *vnode if the outline corresponds to an external file. *The problem* For *all* outlines, Leo calls LeoFrame.createFirstTreeNode to create the root vnode. The root vnode is given a *new* gnx. Normally, this new gnx can't conflict with the gnx in any about-to-be-read .leo file. However, a conflict *can* happen when Leo's bridge reads several .leo files in less than a second. *The solution* I considered eliminating createFirstTreeNode entirely. However, this would cause ripple effects throughout Leo's startup code.The new code might well be more complex and dangerous than the existing code. I'll omit the gory details. Suffice it to say that I won't do this. Instead, I plan to solve the problem entirely in leoBridge.py. Vitalije suggests a straightforward hack: 1. Before reading the .leo file, bridge.openLeoFile (via its helper, bridge.createFrame) will assign a dummy gnx to the root vnode. This dummy gnx will be different from c.hiddenRootNode.gnx. 2. After reading the file, bridge.openLeoFile will give the root vnode a new, unique, gnx *only if* it still contains the dummy gnx. This can happen if the given file name does not exist. *Summary* This is a tricky topic.This post omits discussion of various preliminary researches. The proposed solution should work, but only because the bridge opens all outlines using bridge.openLeoFile. I'll delay Leo 5.2 b1 for at least a week after merging the gnx branch into devel. All questions, comments and suggestions are welcome. Edward P.S. At present, fc.getLeoFile calls checkOutline, which then calls c.checkGnxs. This ensures that all outline nodes have unique gnx's. It's not clear to me whether these checks will be needed after fixing #1437, but I have no plans to remove them. EKR -- 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/0ddcc69d-496e-46a7-a3b2-8536eb448c42%40googlegroups.com.
