On Wed, Jan 18, 2012 at 5:57 PM, Terry Brown <[email protected]> wrote: > On Wed, 18 Jan 2012 17:00:32 -0500 > Seth Johnson <[email protected]> wrote: > >> First, I think you answered the question: no. But I'm still unclear >> what a cross-file clone is. Is it a clone that's in the one leo file, >> pointing at external file A, while within the @file branch for >> external file B? > > I was going to say it's a clone which occurs in two @<file> derived > files in the same Leo outline. But even occurring in only one @<file> > and somewhere else in the outline (but not in an @<file>) can create > confusion when the @<file> is modified externally. I suspect external > modification is the real bugbear here.
Right. But what that means is templating -- producing an external file made up of pieces of other files that can be changed dynamically. At present, clones within @file branches are for that purpose. That's different from maintaining a codebase, where you put functions into specific files and that's the sort of structure you're building, if you're using redundant code, you're doing macro expansion that happens when you compile the code. You're not doing templating. >> If that's the case, it strikes me that part of the problem is that -- >> I think -- the cross-file clone is already being treated like a >> templating function -- isn't that what you'd mean by having a clone >> for file A inside the @file branch for file B? >> >> I think templating in that pattern is different from cloning in the >> sense Edward uses them. > > Exactly - Edward uses them for creating views, typically of code > although they could be views of other kinds of data. That's what I > think you're calling a codebase, although I think the term view is > better. But it seems like others are trying to use them to generate > output with repetitive elements, presumably because they're unaware of > more appropriate tools for doing that, and Leo's clones seem to offer a > solution to their problem. I meant by codebase the collection of external files that you compile. That doesn't use templating. Edward doesn't do templating because he's maintaining code and templating is not a useful function for that purpose. Views are more useful in that case. You use views because you're trying to look at the external file's content in various ways, without changing the structure of the external file except deliberately. You want to do that for code, and for other kinds of data. Templating, on the other hand, is about creating whole new files from pieces of other files. > In response to your other post, I think providing templating tools in > Leo would be a completely unrelated to clones. They'd be more like > section references which could refer to content in a much broader range > of places (vs. section references referring to content in the node's > children). Okay, you could have it unrelated to clones, but it is also unrelated to maintaining a codebase with @file branches. I think templating should be done without using @file -- instead use a special @template thingie for derived files that are going to be produced by dynamically updated bits of text via clones or section references. @file should be for derived files that don't use dynamically updated bits from elsewhere, but just feed the Leo outline so Leo can let you reorder their contents within Leo while letting Leo keep the external file's actual structure in place. @template would be for letting you arrange things in Leo, even across files, and have that reflected in a new, hybrid derived file. @file would not have clones under it within Leo, and would be for derived files that just feed Leo so you can arrange things in Leo without changing the structure of the external file unless you specifically define the structure change. Of course, Leo automatically produces that structure for certain kinds of codebases. For code views in Leo, just plain headers with clones under them. Seth -- 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.
