Re: Clones in @file output only one code block

[Matt Wilkie]

I get the same behaviour. I thought might be because Leo detected a
syntax error or something in the code, but it persists when I use .txt
instead of .py. I encourage you to file a bug.

Copy & paste as node (ctrl-shift-v) the following into leo to reproduce:

<?xml version="1.0" encoding="utf-8"?>
<!-- Created by Leo (http://webpages.charter.net/edreamleo/front.html) -->
<?xml-stylesheet ekr_test?>
<leo_file xmlns:leo="http://www.leo-editor.org/2011/leo" >
<leo_header file_format="2"/>
<vnodes>
<v t="maphew.20120705210033.1396" a="E"><vh>@file myCode.txt</vh>
<v t="maphew.20120705210033.1397" a="E"><vh>function 1</vh>
<v t="maphew.20120705210033.1399"><vh>block 1</vh></v>
<v t="maphew.20120705210033.1400" a="E"><vh>block 2</vh>
<v t="maphew.20120705210033.1401"><vh>block 2, sub 1</vh></v>
</v>
</v>
<v t="maphew.20120705210033.1398" a="E"><vh>func2</vh>
<v t="maphew.20120705210033.1402"><vh>func2, block 1</vh></v>
<v t="maphew.20120705210033.1400" a="E"></v>
</v>
</v>
</vnodes>
<tnodes>
<t tx="maphew.20120705210033.1396">Attempt to reproduce something
reported by Felix74 on leo-editor. Given the following structure, why
does the clone `codeBlock1b` (and children), not get written to
myCode.py in function2?

function1
codeBlock1a
codeBlock1b
codeBlock1bi
function2
codeBlock2a
codeBlock1b(clone)

@others
</t>
<t tx="maphew.20120705210033.1397">this is func1
</t>
<t tx="maphew.20120705210033.1398">this is func 2
</t>
<t tx="maphew.20120705210033.1399">this is func1, code block 1

</t>
<t tx="maphew.20120705210033.1400">this is func1, code block 2
it is a clone
</t>
<t tx="maphew.20120705210033.1401">this is func1, block2, sub1
a child of a clone</t>
<t tx="maphew.20120705210033.1402">this is func2, block 1
it should be followed by a clone, block 2, from func1.
And indeed it is in the leo file, but not in the @file.</t>
</tnodes>
</leo_file>



On Sun, Jul 1, 2012 at 10:16 PM, felix74 <hju...@googlemail.com> wrote:
> Just started using leo and have the following problem creating python
> program using @file
>
> Outline
> =====
>
> @file myCode.py
> function1
> codeBlock1a
> codeBlock1b
> codeBlock1bi
> function2
> codeBlock2a
> codeBlock1b(clone)
>
>
> when the file myCode.py is created function1 contains all the code in
> codeBlock1a and codeBlock1b(+ subnodes).
> However, function2 only shows codeBlock2a and codeBlock1b(+ subnodes) are
> missing from myCode.py.
>
> How do I get codeBlock1b(+subnodes) to be output to file myCode.py in
> function2? I am using @others to insert codeBlock(s) into the file. All the
> code that goes into myCode.py is created inside leo.

[felix74]

Thank you Matt for verifying my observation and the example node to demonstrate the bug.

I've just searched through the bugs and found this https://bugs.launchpad.net/leo-editor/+bug/882243

So I guess that this is a known issue. Unfortunately, It doesn't appear to be considered to be a serious bug and will not be fixed anytime soon.

[Terry Brown]

On Thu, 5 Jul 2012 22:14:21 -0700 (PDT)
felix74 <hju...@googlemail.com> wrote:

> I've just searched through the bugs and found this
> https://bugs.launchpad.net/leo-editor/+bug/882243
> So I guess that this is a known issue. Unfortunately, It doesn't appear to
> be considered to be a serious bug and will not be fixed anytime soon.

I've just switched it from Wishlist to Medium and posted this comment
on the bug:

I think this bug should be revisited. I've switched it from Wishlist to
Medium - let's either get it fixed to do what people expect, or switch
it to Invalid with a definite ruling on why it's invalid.

It seems that unless there's a definite reason not to change it, i.e.
changing it would break some existing workflow, it should be changed on
the "avoid surprising the user" principle. I know changes to the
read/write code are a big deal, but it seems this could be changed at
least to see if it breaks any unit tests - after that it might be a
case of letting it out in the wild to see what happens.

Cheers -Terry

[Edward K. Ream]

On Fri, Jul 6, 2012 at 9:20 AM, Terry Brown <terry_...@yahoo.com> wrote:
> On Thu, 5 Jul 2012 22:14:21 -0700 (PDT)
> felix74 <hju...@googlemail.com> wrote:
>
>> I've just searched through the bugs and found this
>> https://bugs.launchpad.net/leo-editor/+bug/882243

> I've just switched it from Wishlist to Medium and posted this comment
> on the bug:
>
> I think this bug should be revisited. I've switched it from Wishlist to
> Medium - let's either get it fixed to do what people expect, or switch
> it to Invalid with a definite ruling on why it's invalid.
>
> It seems that unless there's a definite reason not to change it, i.e.
> changing it would break some existing workflow, it should be changed on
> the "avoid surprising the user" principle. I know changes to the
> read/write code are a big deal, but it seems this could be changed at
> least to see if it breaks any unit tests - after that it might be a
> case of letting it out in the wild to see what happens.

I'm convinced. I hesitated to fix this because it didn't seem like a
big deal, and because there is a workaround, but it looks like not
fixing this bug is just wasting all of our time.

Not sure when I'll get to this: I'm deep in the static type checking
code just now.

This bug will be safe to fix in the trunk, using a coding pattern that
arose after this bug was reported. I'll define a constant in
leoGlobals.py, say g_clone_fix. All changes will be enabled or
disabled using this constant. This allows an easy "out" if unexpected
problems arise. The constant also highlights the changes after they
are published for wider testing.

Edward