I'm not sure refresh - from - disk is immune to these problems. Nothing specific, sorry, but I feel like I've seen it so some of the headline / recovered node type stuff. Not sure though. Surely it uses a lot of the same read code? Perhaps assessing the differences between @<file> types is important?
Cheers - Terry On June 20, 2017 2:40:49 AM CDT, "Edward K. Ream" <[email protected]> wrote: >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. -- Sent from my Android device with K-9 Mail. Please excuse my brevity. -- 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.
