Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Section Reference causes clone on Leo-Editor file open #132
A cloned node reappears every time a particular Leo-Editor file is opened, no matter how many times you delete the clone and save the file without the clone, the clone reappears when the file is opened.
My best guess is that the crucial circumstances causing the bug are: (1) The triggering syntax must be in an @file. The type of the @file doesn't matter. (2) The section reference must be in the grandparent of the section node.
No errors are reported to the log pane. No errors are reported to the terminal.
Put the following two files into any one folder.
I first noted this bug on 2014-12-31 Wed using commit ad0392f
I have verified that the bug still exists using commit f6cdb2b
The original bug report clearly demonstrates that the bug is in the write logic. The .leo file contains:
As you can see from the given .py file, there are two @+node sentinels for Child, so the read logic is perfectly justified in creating the clones. Note: There are two @Others statements. One would expect that the output logic would write
This is the "real" cause of the bug.
seems to be necessary in order create a placeholder node for child to which the
Experiment 1: Deleting the line:
and reloading Leo yields this (more typical) outline:
Alas, this outline doesn't match the original outline.
Experiment 2: The following .py file recreates the original outline:
To make this work, the write code must write the @+middle node completely, and the write code must remove Child from the pending list of nodes to be written by @Others.
Any change to Leo's write code is, in fact, a major change to Leo. Happily, the affect code is never used in typical Leo outlines. At present, it does not appear that Leo's read code needs to change, but that is far from proven.
rev e10a989 appears to fix this bug, completely and safely:
Imo, this is a fairly minor change to Leo's read/write code, as far as such major changes go ;-) Please report any problems, no matter how seemingly small.
Your fix appeals to me.
I have verified that now Leo-Editor handles test sectionCausesClone.leo in a reasonable manner.
But it is unfortunate that Leo-Editor does not display a warning when it changes the tree structure.
In the sectionCausesClone.leo case, the "section" node is moved up one level in the tree.
The other case that I've noticed was when I wanted four or five "section" nodes to be in an order different from the order of the "section" references in their parent node. No matter how many times I wrote the .leo with the nodes in my desired order, when I re-opened the file, they were in a different order.
As you pointed out they were in the order of the "section" references and that is the only node order information in the .leo file. So Leo-Editor can't notice the change on the read, but would it be too much trouble to notice the problem on the write?
In the sectionCausesClone.leo case, would it be too much trouble to display a warning on the write or read?
So far I'm one of only two people who have reported noticing unrequested tree structure changes. Consequently, I would give adding warning messages very low priority.
Thanks for this confirmation. I appreciate it.
I don't believe this can ever change. The present read code is not simple, and it does honor the data in the external file. Once can imagine "heroic" attempts to retain existing outline structure, but I've already gone down that road with the ill-fated "View" project. See:
Yes, I know that there are languages for which sections must substitute for proper classes and methods. But I am not going to make any major changes to Leo's read code.
Easy enough, but pretty much pointless, imo. The warning would quickly become noise, as all such warnings do. The only solution, it seems to me, is to put section definitions where they logically belong in the @file tree. If you want to manage those sections in other ways, do so in an organizer node outside the @file tree. You then have complete freedom.