On Sat, Feb 28, 2015 at 6:26 AM, Kent Tenney <[email protected]> wrote:
> So, the purpose of the "Recovered Nodes" tree is to address potential > issues > > only related to clones? > That's the most common use. There may be other situations in which these nodes can be created. When using @clean, the tip-off that something has changed is an "updating" message in the log pane. Sorry to be so vague. Let's look at the code. fc.handleNodeConflicts creates the actual "Recovered Nodes" nodes. The new setting causes this method to put a single message to the log instead of creating the nodes. fc.handleNodeConflicts creates the nodes from c.nodeConflictList, so the "real" answer as to what is going on relates to how items get put on c.nodeConflictList. Let's do a clone-find-all-flattened on nodeConflictList... - cacher.reportChangedClone updates c.nodeConflictList. So caching checks for updated nodes. A good thing. - c.refreshFromDisk inits c.nodeConflictList, then calls fc.handleNodeConflicts if the list become non-empty. Check. - at.indicateNodeChanged adds an item to c.nodeConflictList. - A clone-find-all-flattened on indicateNodeChanged shows that it is called only from at.terminateBody, part of the @file logic. In short, we expect that Leo will recovered nodes as the result of reading an @file tree, whether during the initial load or as the result of refresh-from-disk. HTH. 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/d/optout.
