First, thanks for your comment. I'll related to them at each section. In general, though, I was trying to provoke some thinking on the greater uses of clones, beyond what is currently supported by Leo, in the hope that it can be refined through discussion to something which may expand Leo's functionality and increase its usefulness even more.
> > The second use case is “clones > > for synchronization”. I think someone described this use case as using > > Leo as a macro processor. Indeed I find myself using Leo to sync > > between files or portions thereof. It is especially useful for > > languages that do not have functions, e.g. HTML. > > I would say there are two separate use cases here: > > A. Using clones *within* a file, as macros. This does indeed > compensate for HTML's (and XML's) lack of functions. > > B. Using clones *across* files, to synchronize files. I regard this > case as dangerous. I use this capability in a weak way, to save > projects and to-do items in leoProjects.txt, leoToDo.txt, etc. These > files have @all directives, and due to the recent changes to Leo's > file code, these "@all-files" can never override clone definitions in > .leo files or other external files. > > In other words, the point of the recent critical bug fix was to make > sure this use case is safe. Relying on Leo to keep n...@all external > files in sync using clones is not recommended, by me at least :-) You > are asking for pain due to a classic multiple-update problem. > > Edward I accept the differentiation between A & B, but I could not point to any practical difference in handling them. A may still result a clone conflict (being "multiple source" one), as, of course, B. I am not sure that @all is the key thing here, while, again, I recognize the this is the current state of Leo. I think the more basic distinction should be between @file like directives (@file in the greater sense of @thin, @shadow, etc.) for which Leo reads the external content, and which therefore may result with clone conflicts, and those for which it does not. I think that any case where Leo reads an external file and does not reliably represents its content should be eliminated. Otherwise, Leo presents a false picture to the user of the content of the environment. If I analyze correctly, this may currently happen in the following situations: 1. On a clone conflict, where currently the last node wins and this is problematic for "multiple source". 2. Using @all, which is something a bit new, described above. Is that good? It is a difficult logic (if I captured it right) - Leo reads the external @file, but runs down any clone within it, which Leo already knows about. Gil -- 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.
