About bug 882243: clones sometimes not saved

[Edward K. Ream]

https://bugs.launchpad.net/leo-editor/+bug/882243

I'd like to discuss this bug here, because I would like us all to be
aware of the situation, and possible changes.

The surprise
=========

To paraphrase the original bug report, suppose we have the following
@file tree:

+ @file test.txt
@others
+ node 1 (cloned)
node 1 text.
+ node 2
@others
+ node 1 (cloned)
node 1 text.

As usual, lines preceded by "+" denote headlines: all other lines are
body text.

The surprise is that the cloned node1 node is written to the external
file only once (as a child of the root node) and hence does not appear
as a (cloned) child of the node2 node when Leo next loads the @file
tree.

History
=====

I would like to call this a wishlist item because the present code
quite intentionally writes *any* node (including cloned nodes) only
once. That is, the write code sets a bit when writing a node, and
@others ignores any nodes with that bit set.

You could call this a bug in the @others write logic, but at one time
it was done explicitly and on purpose.

I don't remember why this was so, but I do remember it *was* so. It
may have been an artifact of Leo's old representation of clones that
used both vnodes and tnodes. tnodes no longer exist in the one-node
world that we have been living in for several years, and it may well
be time to revisit the original design, but I would rather not do that
just now because there are several "real" bugs that need attention
asap.

Workaround
=========

Because this is an issue involving @others, you might assume that a
workaround involving sections would be possible. You would be
correct. The following file works as expected::

+ @file test.txt
<< node 1 >>
<< node 2 >>
+ << node 1>> (cloned)
node 1 text.
+ << node 2 >>
<< node 1 >>
+ << node 1 >>(cloned)
node 1 text.

All comments welcome.

Edward

[HansBKK]

"as expected" seems to be in the eye of the beholder 8-)

On Friday, December 16, 2011 11:38:39 PM UTC+7, Edward K. Ream wrote:

https://bugs.launchpad.net/leo-editor/+bug/882243

I'd like to discuss this bug here, because I would like us all to be
aware of the situation, and possible changes.

The surprise is that the cloned node1 node is written to the external
file only once (as a child of the root node) and hence does not appear
as a (cloned) child of the node2 node when Leo next loads the @file
tree.

This wasn't a surprise to me due to my ignorance, as I only used @others in the file-root (as you're now enforcing with @all).

 

Because this is an issue involving @others, you might assume that a
workaround involving sections would be possible.  You would be
correct.  The following file works as expected::

+ @file test.txt
<< node 1 >>
<< node 2 >>
  + << node 1>> (cloned)
     node 1 text.
  + << node 2 >>
     << node 1 >>
    + << node 1 >>(cloned)
       node 1 text.

That this was possible was the surprise - to me. 8-)

Now that I know this, it seems like yet one more way - and so far the most explicit/visible and therefore safest way - to avoid data loss due to clone wars. Unfortunately, my current use case does require outputting cloned nodes into different files and folders.