On Tue, Dec 6, 2016 at 12:47 PM, 'Terry Brown' via leo-editor < [email protected]> wrote:
Clones are really really good for creating task specific views of > code, by gathering together all the nodes relevant to a particular > development task, so you don't have to constantly scroll up and down the > outline to get to the relevant pieces. > I agree. clones create a focus of attention. Furthermore, it's possible to manipulate the result using all of Leo's outlining capabilities. > "Code" could be a manuscript or other non-computer related document that > requires editing in multiple places. > Yes. > Who uses them that way? Well, Edward, certainly, and probably a lot of > other people. Clones are fairly safe to work with in this role, although > I'm sure there are still ways they can have unexpected side effects. > There are no "unexpected" side effects. However, it's possible to make mistakes with clones. There's a big difference between these two statements. As an example of a mistake, I have moved a node out of an @file tree, when I thought I was moving its *clone *out of the @file tree. This deletes code from the external file. And there are other "Leonine" mistakes that can be made. For example, forgetting to include an @others directive. Leo will warn about that in @<file> trees, but not in scripts. Yes, such mistakes can only be made in Leo. That doesn't mean that Leo makes programming more error prone ;-) > In this role, you typically only have one occurrence of each clone in a > @file, the rest are in the Leo outline itself, but not in places written to > external files. This makes them less likely to bite. > Yes. That's exactly how I use clones. What else do people use them for? Template / snippet replacement for > recurring elements like headers and footers in websites, blogs, and in > code. This seems to be the context that people most often (a) get lyrical > about how unique Leo is for providing this great workflow, and (b) run into > trouble because of the tricky nature of cross file clones. > Yes. I don't recommend cross-file clones, even if the code is (momentarily) identical. Better to clone *copies* of code, one copy per file. Something like: @file a.txt - common code (a.txt) # cloned as desired to duplicate code @file b.txt - common code (b.txt) # cloned as desired to duplicate code This is better style, and safer, even if the common code initially starts out to be identical in both file. With this pattern, the common code in a.txt can't easily be confused with similar code in b.txt. Better, the code in each file can evolve separately. If you truly want the code always to match, you can really use cross-file clones. Better, if your language allows it, you can replace the clones entirely by a reference to common code in a third file. And if your language doesn't allow it, you could consider writing a prepass script that will pull in the desired code/text from either an external file or an outline node. The common code could even be a child of the script... I can see why people are attracted to clones for this second category of > uses, but I'm really not sure they're the best choice. In code, wanting to > repeat things may indicate bad design, you can usually define something > somewhere and reference it by name in the manner appropriate to the > language you're using. For things like website headers / footers, there are > a lot of other ways without the extra load of avoiding cross file clone pit > falls. Websites typically use so > > me kind of templating system like http://jinja.pocoo.org/docs/dev/. And > you can still leverage Leo to handle things like website headers / footers > without clones. A *small* script could run through an outline generating > web pages with common header / footer content pulled from Leo nodes. > Yes. I am in complete agreement, as indicated above. > > Finally, for the task specific code view case, I prefer alternatives which > may not be *quite* as fluid and seamless as clones (mainly for UI reasons), > but have no sharp edges you need to be wary of. The bookmarks, tagging, and > backlinks plugins are all options in this case, with the first two being > particularly usable. > We disagree slightly on this one. And that's fine with me. Not everyone has to be a clone-meister. I don't believe there are any "sharp edges" with clones. They are sound. However, they do require a bit of care so that you don't accidentally delete code. The rules aren't that hard, but some may find those rules mentally fatiguing. I *completely* understand that kind of fatigue. I don't suffer any at all regarding clones. The rules are second nature to me. But exactly that same kind of fatigue is why I find vim intolerable. Thanks, Terry, for a superb summary of clones. 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 post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/leo-editor. For more options, visit https://groups.google.com/d/optout.
