On Wed, Jan 18, 2012 at 6:46 PM, Seth Johnson <[email protected]> wrote: > irritating minor clarification below > > On Wed, Jan 18, 2012 at 6:43 PM, Seth Johnson <[email protected]> > wrote: >> On Wed, Jan 18, 2012 at 5:57 PM, Terry Brown <[email protected]> wrote: >>> >>> 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.
I think external file modification will be far easier to work out once templating and code maintenance are treated as separate functions, that users clearly switch between. (And this will make easier all the issues of collaboration and versioning -- and potentially distribution -- that are also related to the external file modification problem, even after you sort it out just for the case of one local user, or some protocol among several users) (eom) >>> 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.
