On Mon, Mar 2, 2009 at 9:44 AM, edgimar <[email protected]> wrote: > > What does anyone think about the idea of having @leo nodes, which can > include .leo files?
Something like this has been suggested many times. In the past, I have not been receptive to this idea, but just now I do not remember why. This is one of the advantages of a less-than-perfect memory :-) > > Then, since a .leo file just represents a set of top-level nodes, the > children of this @leo node would simply be all of the top-level nodes > in the .leo file. > Of course there would need to be checks done to > prevent recursive loops, but it could (would) be a powerful way of > using leo. By "recursive loops", I suppose you mean that the "imported" .leo file might contain @leo nodes. 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. The memories are starting to come back. It is this kind of consideration that gives me pause. > > If such a capability were to be implemented, I could see the benefit > of two related operations: (1) an operation which would turn an @leo > node into a normal node (i.e. if the @leo node in x.leo referred to > y.leo, then all of the contents of y.leo would be incorporated into > x.leo, and the reference to y.leo would be removed), and (2) an > operation which would allow any node to be turned into an @leo node > (i.e. removing the node's contents from x.leo, and creating a y.leo > file which is now only referred to in x.leo). The copy-node and paste-retaining-clones do this, should you actually want to incorporate nodes in two separate outlines. But, imo, this kind of physical inclusion is not a good idea: it is much better style to put information in a single place. The present mess with bugs reports in at least three separate locations illustrates the problems... In conclusion, I think it might be time to do @leo, but not as you suggest. There are a number of subtle data-management issues within Leo that would get harder in the presence of @leo as you envisage. 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. This simpler kind of @leo can probably be done in less than 20 lines of code. Would you like to try? Eventually, this simpler kind of @leo should be an official part of Leo. 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 -~----------~----~----~----~------~----~------~--~---
