> By "recursive loops", I suppose you mean that the "imported" .leo file might > contain @leo nodes.
I mean, for example, in a.leo we have "@leo b.leo", and in b.leo we have "@leo a.leo". (or a->b->c->a, etc...) > More importantly, imo, there would have to be ways of "unifying" @<file> > nodes that are intended to refer to the same external file. Such nodes > should become clones. The problem is, how is that to be done? Leo has no > real mechanism to do "cross-file" clones. Furthermore, the so called hidden > machinery in, iirrc, @thin nodes, must be merged somehow. I picture creating some kind of adapter between a leo file and a node -- if I'm not mistaken, Leo currently implements nodes as objects which are simply pointers to text block objects. But I'm fuzzy on how the tree structure / node relationships are stored. Whatever the case, you would need, for each @leo file, a complete new set of datastructures for storing node-relationships and text blocks for that file. I think the challenge would be to know how to deal with the case when someone wants to clone a node across .leo file boundaries. Initially, the easiest might be just to forbid clones across .leo files, but maybe there is some way to do this...? > Rather than having @leo physically importing nodes, I would prefer that @leo > simply opens another outline. This would still be useful, and it would > avoids deep complexity. One of the advantages of the 'non-trivial' implementation, as I see it, would be the ability to search through all of the nodes, including the nodes of @leo subtrees. If it simply opened another outline, this would not be possible. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
