On Tue, Apr 8, 2008 at 8:09 AM, bobjack <[EMAIL PROTECTED]> wrote: Uhm... This looks more complicated than I thought. All the more reason > to encapsulate it and hide the details from plugins and scripts I suppose > ... > > Am I right in thinking > > a) that stuff put on tnodes appears on all clones and stuff put on if > vnodes, only that position in the tree, not the other clones of it?
Yes. All cloned nodes share the same tnode. Furthermore, **there is only one tree of descendants** that contains the common descendants of clones. The shared subtree of two cloned nodes v1 and v2 (v1 != v2) is v1.t._firstChild. This is the **same** as v2.t._firstChild because v1.t == v2.t. In the **old** terminology, the descendants of cloned nodes where *joined*. But in the new (Leo 4.x) world, it's not that nodes are joined, it's that there is only one set of descendants. This includes **vnodes**. b) stuff can't be put on vnodes in @thin files? One moment while I look this up :-) Ok. I searched for "hidden machinery" in leoDocs.leo. Here is what I found (reformatted for clarity): @@@ **Important**: Plugins must *not* use v.unknownAttributes inside @thin trees. Indeed Leo uses **hidden machinery** to write t.unknownAttributes. Leo does *not* write t.unknownAttributes to thin derived files. Instead Leo writes a representation of all t.unknownAttributes contained in the @thin tree to a special xml attribute called descendentTnodeUnknownAttributes in the <v> element corresponding to the @thin node. Yes, this is complicated, but it works. Leo can *not* write v.unknownAttributes in @thin trees because **only tnodes have gnx's in in derived files**. In effect, vnodes are anonymous. Plugins that must associate attributes with vnodes should support only @file trees. A completely different alternative would be for the plugin to extend how Leo reads and writes <v> elements in .leo files, but that would be much more complicated than using t.unknownAttributes Here are the details about how Leo associates uA's with <v> and <t> elements in .leo files: - **Native xml attributes** are the attributes of <v> and <t> elements that are known (treated specially) by Leo's read/write code. The only native attribute of <t> elements is tx. The native attributes of <v> elements are a, t, vtag, tnodeList, marks, expanded and descendentTnodeUnknownAttributes. All other attributes of <v> and <t> elements are **foreign xml attributes**. - When reading a .leo file, Leo will create t.unknownAttributes or v.unknownAttributes ivars for any tnode or vnode whose corresponding <v` or <t> element contains a foreign xml attribute. - When writing a file, Leo will write foreign xml attributes in <v> or <t> elements if the corresponding vnode or tnode contains an unknownAttributes ivar. - Leo performs the usual xml escapes on these strings when reading or writing the unknownAttributes ivars. QQQ The question is, what does this mean :-) I think the short answer is that the present scheme, involving descendentTnodeUnknownAttributes, does not allow information contained in vnodes in @thin trees to be saved. However, a plugin could create a foreign attribute of the **root** vnode of the @thin tree. Leo would save this attribute as usual (in the .leo file), and with enough cleverness the plugin could associate info in this attribute with (reconstituted) vnodes. It won't be pretty, but it might be possible. HTH. 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 -~----------~----~----~----~------~----~------~--~---
