This proposal incorporates ideas from the "Semantics of coping clones" thread. Imo, this proposal solves all the problems that have been discussed, with additional benefits.
*Motivating ideas* 1. We want one or more *indivisible* (atomic) operations that copy a template and paste it following c.p. Because the operations are atomic, they will work as expected when done twice. 2. We want a flexible, general way of indicating which nodes are candidates for being clones after the paste. 3. We want to refer *by name* to templates defined in myLeoSettings.leo or leoSettings.leo. *@templates and @template nodes* Leo will support @templates and @template nodes in @settings trees. Only one @templates node should exist in an @setting tree. Each @template node should be a direct child of the single @templates node. Each @template node will specify a *template name*, like @template django-template. The template consists of *all* the descendants of the @template node. A template can contain multiple nodes. *Template-related commands and methods* The *prompt-for-template* command will enter the minibuffer and aks the user for the name of a template. Tab completion will show the existing template names. The *c.insertTemplateByName*(template_name) and *c.insertTemplate*(p) methods will make it easy to insert templates using @button or @command nodes. All these commands and methods will be atomic: they will find a template, copy it to the clipboard, and then do paste-retaining clones. *Handling clones* All cloned nodes in the children of an @template tree become* candidate clones*. They will actually become clones if the paste-retaining-clones makes them clones. Now we can see why the @templates node exists. It provides a convenient place to define clones *outside *of any @template (singular) node. In effect, these *external clones* mark nodes *inside* @template nodes as being candidate clones. There is no need to use marks. *Note*: If the gnx of a cloned node in a template matches the gnx of any node in the file receiving the template, then the template node *will* become a clone after, say, c.insertTemplateByName. The user can "transfer" gnxs to templates in myLeoSettings.leo using paste-retaining-clones. *Summary* The scheme proposed here is more general and flexible than those discussed so far. It will require straightforward extensions of Leo's existing settings machinery. There is no need for an alternate version of paste-retaining-clones. I encourage all questions and comments :-) Edward -- You received this message because you are subscribed to the Google Groups "leo-editor" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/leo-editor/bb3d249f-961c-430f-abe7-74c92ab54ad1%40googlegroups.com.
