Some people seem to think that it is difficult to understand how Leo
handles "clone wars": differing values for a cloned nodes that appear
in several external files. That's not true. The rule is::
**The last clone that Leo reads wins.**
That is, for any cloned node C, Leo takes the value of C.h and C.b to
be the values specified by the last copy that Leo reads.
There is only one complication::
**Leo reads the entire outline before reading any external
files.**
Thus, if C appears in x.leo, y.py and z.py, Leo will choose the value
for C in x.py or y.py, depending on which @<file> node appears later
in the outline.
Notes:
1. Whenever Leo detects multiple values for C when opening an outline,
Leo creates a "Recovered nodes" tree. This tree contains all the
various values for C, nicely formatted so that it is easy to determine
where the differences are.
2. I've just refreshed my memory by looking at the code. The relevant
methods are:
fc.getLeoFile # Reads the outline, then calls at.readAll to read
all external files.
at.indicateNodeChanged # Adds data to c.nodeConflictList
cacher.reportChangedClone # Adds data to c.nodeConflictList
fc.handleNodeConflicts # Creates "Recovered Nodes" node and its
children.
3. The present code is the simplest code that could possibly work.
There is no way Leo is going to do AI in order to implement complex
rules for which clones are "more important" than others. Thus, if you
use cross-file clones, it is up to *you* to know these rules and
handle any resulting conflicts. Imo, the "Recovered Nodes" feature is
a big step forward for Leo, and makes it impossible to lose data
unless you willfully refuse to examine the data.
Edward
--
You received this message because you are subscribed to the Google Groups
"leo-editor" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/leo-editor?hl=en.
