This is an Engineering Notebook post--notes to myself. It will form the basis of an urgent enhancement item.
Terry, please read this carefully. This is a big deal. There are several severe problems when switching between git branches, arising from long-standing quirks in Leo's read logic. This quirks are no longer tolerable. The quirks gives rise to the "Recovered Nodes" tree. Imo, this whole mechanism probably should be scrapped. This is ironic, for several reasons. First, someone has just called this mechanism a work of genius. Second, I recently suggested that the *form* of the recovered nodes might be the basis of a set of git diff commands. (That's still true.) Third, just yesterday I swapped the args to difflib.Differ.compare used to create the summary diff in each recovered node. At least in *some* cases, the diffs are backwards! *The problems* *Clones in the .leo file have too much influence.* Particularly when switching git branches, we want the external file to override clones appearing in the .leo file. Yes, clones could be defined in two separate external files. Imo, Leo should warn about clone conflicts *only* when the conflict arises from two conflicting external files. In all other "conflicts", *the data in the external file must rule*. *Headlines in the .leo file have too much influence.* It's incredibly annoying when headlines in the .leo file override the corresponding sentinels in the external file. Not sure exactly how and why this happens, but it does happen. *The "last clone wins" rule is dangerous nonsense.* This rule says that when there is a conflict between clones, the data in last clone in the .leo file wins. This is wrong, wrong, wrong. Again, the data in the external file must rule. Alas, there is some reason for this nonsense. "Summary" files, like leoProjects.txt, contain a mishmash of clones in an @all tree. Typically (I think) these clones are written in sync with changes to the "master" external file, but I should verify this. Anyway, these summary/@all files should have lower priority in case of clone conflicts, *regardless* of their place in .leo files! *Recovered Nodes trees are misleading.* Switching git branches often results in wholesale changes to code, but Leo reports changes only in *cloned* nodes. Imo, this makes no sense whatever. There is *nothing* special about changes to cloned nodes! *A workaround: refresh-from-disk* Yesterday I realized that the refresh-from-disk command (probably) suffers from none of the problems listed above. In particular, refresh-from-disk deletes all children of the @<file> node before reloading the file. This makes it impossible for Leo to generate so-called "resurrected" nodes, another confusing feature of Leo's read logic. It also makes it impossible (less likely?) for headlines in the outline to override corresponding sentinels in the external file. *Summary* Leo's existing read logic is at least a decade old. There have been hints of trouble in the past, but the troubles with git branches are now intolerable. Happily, git also provides recovery options that did not exist 10 years ago. Recovered nodes trees are wildly misleading. They highlight only changes to cloned nodes, ignoring all other changes. Imo, such trees should be created only for conflicts involving two separate external files. Also, "resurrected" nodes should never, ever, be reported. The node structure of external files should rule, without warnings. Period. refresh-from-disk is a *proof of concept *of a "proper" read logic, one that makes data in external files override clones that appear outside of any @<file> node. Alas, refresh-from-disk has no way of detecting clones that may be defined in multiple external files. For this and other reasons, I doubt that refresh-from-disk can be a drop-in replacement for Leo's read logic. Major, dangerous, changes will be required. The work clearly must be done in a separate branch. All comments welcome. 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 https://groups.google.com/group/leo-editor. For more options, visit https://groups.google.com/d/optout.
