On Sun, Jan 24, 2010 at 3:15 PM, Gil Shwartz <[email protected]> wrote: > Gui Suggestions > > 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. > 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. 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 -- 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.
