Clones - what are they good for?

[Terry Brown]

(How I feel about clones, YMMV)

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.  "Code" could be a manuscript or other non-computer related document that requires editing in multiple places.

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. 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.

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.

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 some 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.

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.

Cheers -Terry

[Largo84]

Nice post, Terry. I use clones extensively for both scenarios you mention below. I try to avoid using them for repeatable text snippets wherever possible by creating and referencing small external text files, but that's not always practical. The biggest problem I would have in getting away from them altogether is that while I am quite literate in markup languages (html, LaTEx, etc.) I'm quite rusty when it comes to programming code and writing scripts (my last actual programming was 20 years ago in Pascal, never learned Python). I wouldn't even know where to start writing a script to go through an outline and replace all instances of a block of text with an updated version of same. So for me (at least for now), I will continue to rely on clones until and unless I can find a better alternative. Having said that, I always need to be aware of situations where clones can 'bite' (cross-files and @auto... as I mentioned in another post). Regards,

Rob..........

[Zoom.Quiet]

On Tue, Dec 6, 2016 at 12:47 PM, 'Terry Brown' via leo-editor
<leo-e...@googlegroups.com> wrote:
> (How I feel about clones, YMMV)
>

...

> I can see why people are attracted to clones for this second category of

> .... 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....
>

IMHO, only issue case in coding ;-)
'''... repeat things may indicate bad design''' ~ can not agree more
but, this feeling just only base the release stage of project,
in software more than 80% stage is in chaos,
every things be try/testing/adjusting/etc.
so Leo can very happy ctrl. all kinds of chaos code block,
with section/@others/clone/etc. the software big picture, always under
us design.

for me in coding , clone usage:
- in-sync same config/information in difference file/dir/proj.
- in-sync function code block, but not yet extract as function/class/module
- in-sync temporary demo data, not necessary as data file
- ...

for fix `repeat things`, every cloned node just the target will
replace with one function,
but not in beginning, just with project developing, natural/slowly/one
by one replaced.

PS:
lamentable...most project will die,
before all cloned nodes replace with good look function....


> Cheers -Terry
>
>



--
life is pathetic, go Pythonic! 人生苦短, Python当歌!
俺: http://zoomquiet.io
授: http://creativecommons.org/licenses/by-sa/2.5/cn/
怒: 冗余不做,日子甭过!备份不做,十恶不赦!
KM keep growing environment culture which promoting organization be learnning!

[Edward K. Ream]

​​

On Tue, Dec 6, 2016 at 12:47 PM, 'Terry Brown' via leo-editor <leo-e...@googlegroups.com> 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

[Edward K. Ream]

On Tue, Dec 6, 2016 at 1:24 PM, Largo84 <Lar...@gmail.com> wrote:

I'm quite rusty when it comes to programming code and writing scripts (my last actual programming was 20 years ago in Pascal, never learned Python).

 

​Pascal might have been called state-of-the-art in programming simplicity back in the day.  However, you should understand very clearly that python ​is almost infinitely easier to learn and use than Pascal.​

I wouldn't even know where to start writing a script to go through an outline and replace all instances of a block of text with an updated version of same

​.

​As with any learning, you start at the beginning.  Take safe baby steps.

I never write a script that changes an outline in one go.  At first, the script tells me what it would replace, and where.  When I am satisfied that all is well, I make sure everything is backed up first ;-)  Only then do I run the script so it alters nodes.

It's so  easy to traverse Leo outlines:

   for p in c.all_nodes():

       << do something with p>>

In particular, p.b is the node's body, and p.h is the headline.  You can use either p.b or p.h as a setter or getter, but do not change p itself.

That's enough hints.  Dive into Leo's scripting docs!

So for me (at least for now), I will continue to rely on clones until and unless I can find a better alternative. Having said that, I always need to be aware of situations where clones can 'bite' (cross-files and @auto... as I mentioned in another post). Regards,

​Python is way too good a language to ignore.  Don't be afraid of it.

EKR

[Edward K. Ream]

On Tue, Dec 6, 2016 at 2:14 PM, Zoom.Quiet <zoom....@gmail.com> wrote:

On Tue, Dec 6, 2016 at 12:47 PM, 'Terry Brown' via leo-editor
<leo-e...@googlegroups.com> wrote:
> (How I feel about clones, YMMV)
>
...
> I can see why people are attracted to clones for this second category of
> .... 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....
>

IMHO, only issue case in coding ;-)
'''... repeat things may indicate bad design''' ~ can not agree more
but, this feeling just only base the release stage of project,
in software more than 80% stage is in chaos,
every things be try/testing/adjusting/etc.

​Hehe.
​

 

so Leo can very happy ctrl. all kinds of chaos code block,
with section/@others/clone/etc. the software big picture, always under
us design.

for me in coding , clone usage:
- in-sync same config/information in difference file/dir/proj.
- in-sync function code block, but not yet extract as function/class/module
- in-sync temporary demo data, not necessary as data file
- ...

for fix `repeat things`, every cloned node just the target will
replace with one function,
but not in beginning, just with project developing, natural/slowly/one
by one replaced.

​The most important rule in any kind of engineering is that anything is allowed provided that it works, and works reliably.  If you use clones effectively and safely, then that's good enough.  I certainly won't complain :-)​

 

PS:
lamentable...most project will die,
before all cloned nodes replace with good look function....

Buddhists emphasize "the impermanence of all things"​. Imo, the foundation of spiritual practice is to confront that everything will disappear eventually.

The purpose of this practice is to increase one's sense of joy in the moment, in the world as it is. Everything becomes more keen, more vivid, more sharp, when one sees how fleeting each moment truly is.

EKR

[Largo84]

​Python is way too good a language to ignore.  Don't be afraid of it.

Not fear so much as not enough time to spend to learn it. I agree with another comment you made earlier that the best way to learn is to have a specific task (need) and from that figure out how to accomplish the task. So far I haven't had a compelling enough need to motivate me do it:-) But then, I don't know what I don't know (I think that's called 'blind incompetence'). Thanks for the initial pointers, though.

Rob........