> > I think it is important to differentiate between “zero” and “single” > > source clone types and “multi source clone” type. This can be done > > easily by using double clone arrow for the latter clone type. > > Easily? That's not proven. We could add a "multi-clone" bit to > vnodes, but now every single outline operation could affect that bit. > And how would we set the bit? We somehow would have to coordinate the > sax-read code with the atFile.read code.
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). Therefore, that same way that a change of clone content is immediately reflected by the clone node, so does the bit setting of the clone type. 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. When reading the .leo file we only add internal nodes to the clone so it is obviously of type "zero source". Later, when external files are read, the first node that is added to a clone causes the clone to be of type "single source". Any other node make it "multi source". I think this scheme is fairly simple and robust. 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). > > 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, > > I absolutely refuse to do this, and I will not accept a plugin that > attempts to do this. What you are suggesting would require a complete > scan of the entire .leo file for every move operation. It's a huge > performance hit. > > More importantly, you can not do this to Leo and expect Leo to remain > robust. It may not be apparent, but Leo works as well as it does > because I have made it my top priority to avoid these kinds of global > interactions. Putting such code into Leo is the best way I know to > destroying its integrity. I do not think there is a significant performance hit or global interaction involved. The way I see it, a tree node already have run time information of whether it is a clone node or not. This is obvious, because when a node body is edited, it is immediately reflected by its other clone nodes. So, for the above, only movement of clone node is relevant and not every move operation. The number of clone node is typically a lot smaller from the number of total nodes. Moreover, when moving a clone node, we only need to determine if it has changed state from "internal node" to "external node" and vice versa. This is not a global operation, rather a simple traverse over its parents to look for "@file", "@thin", "@shadow", etc. If we keep the old route to the tree, it typically overlap much of the new route following a single move, so we only need to evaluate to a common patent or the root - whichever is simpler/more convenient/faster. Obviously, this operation is bound by O(node depth), which really cannot be considered global interaction. I hope this makes it more realizable. > As we have just seen, data problems are the most critical problems in > Leo. We simply can not add this kind of complexity to Leo. > > Instead, I suggest you find ways to work around xml's limitations. > You might start with xslt. > > Edward I'm sure sure I understand the relation to XML here. Gil -- 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.
