On Fri, Jan 29, 2010 at 3:39 PM, Gil Shwartz <[email protected]> wrote:
> I think that the type of clone is a property of the clone entity (I am > not sure what the standard terminology is, but I am referring to what > is represented by <t> element in the .leo file, and by "Hidden Root > Node" in a previous comment of Edward). Again, this is a major disagreement between us. What you are calling the "clone entity" is, it seems to me, the same thing as the entire Leo outline (the entire .leo file). I don't want any such outline-wide data dependencies influencing clones!!!! In contrast, the clone-status of any node is simply the number of parents it has. This is a local property of data. True, the clone-status of a node is not an intrinsic property of that node in an external file--it depends on how many other nodes Leo has read. But again, all this gets resolved at read time, and gets modified only by Leo's low-level node methods. This is the way the situation *must* remain. > I do not think that this has anything to do with the sax-read > (assuming here you mean reading the .leo XML file). The bit need not > be stored in .leo. It is computed in run-time as clone nodes are added > to the clone entity. That would be too expensive and too dangerous. The property of being in an external file depends on a large number of factors. Really. The very last thing I want to do is do AI on the entire Leo outline every time any part of the outline changes. In contrast, something like @master is conceivable, as I said earlier. It is a localize request that the node be handled with greater respect by the read code. The write code could check that an @master node not be contained in more than one external file. > As a side comment, I also think that the node name should be an > attribute of the clone entity rather of the clone node (the <v>), but > this is less important for the current discussion (or maybe not, if we > decide on a fundamental treatment to clones). The name doesn't matter much because it can change. But the nodes identity, its gnx, must be an intrinsic property of the node. >> > Every time a clone node is moved, Leo can evaluate if it becomes an >> > external >> > clone node and if it does and the clone entity has more than one >> > external clone nodes That's one case. But renaming an @file node to @@file is another case. Failure to find *all* the cases will create data disasters. It is impossible *in principle* to find all the cases, because this global constraint must be checked every time anyone makes any change to Leo. It's hopeless, and an invitation to having the entire Leo project fail 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.
