@auto-ms does not get along with Leo's clones

[p.os...@datec.at]

An example:

@auto-md file1.md
    clone-node_1
    clone-node_2

@auto-md file2.md
    clone-node_1
    clone-node_2

Changes in a clone causes (don't know exactly when, probably when reading the LEO file) that the tree hierarchy is partially destroyed. The content remains, but ends up in a node that didn't exist before and whose heading consists of parts of the content.

I think this could be prevented if @auto-md would only write. Do I see that right? And can I force this somehow?

Best regards
Paul

[Thomas Passin]

Maybe @clean or even @file would work for you (not that I've tried them with clones, which I'll try out soon) instead of @auto-md.  I don't think  that @auto-md really gets you anything that they don't, although you will need to put @language md at  the start of the body of the top node.

[Thomas Passin]

I tried out what you wrote and didn't get an error with an @auto-md file.  It is only a tiny, simple file so maybe it's not enough of a test.  Here is what I did:

1. Created an @auto-md file with the following structure:

@clean c:\temp\leo\md-test-at-auto-md.md
    Markdown Test Tree
        A1
            A1.1
                A1.1.1
        A2

2. I added a line @others to the top of the body of the top node.  I wrote a line or two for most of the nodes.  Then I saved the outline.

3. I added a new top-level node outside the @auto-md node.  I cloned node A1 into it.

4. In the cloned A1.1 node, I added a new line.

5. I observed in an external editor that the @auto-md file had the intended change.

6. I closed and reopened the outline.

7.  I did not see any corruption in the outline.

Could you write more detail about the @auto-md file that ended up with a corrupted outline, and whether you use an @others line in it?  And is this the only such file that caused a problem?  And also the version of Leo and the OS (though it doesn't seem likely that the OS is playing a part).

[p.os...@datec.at]

@clean (and @file likely so) is not an option, because then the tree of nodes is note converted into markdown sections with the respective headings and their level.

[p.os...@datec.at]

Sorry, it's Leo 6.6.4 on Arch Linux.

[Thomas Passin]

@Edward recently re-worked some of the importers.  If you can use the current version of the devel branch (in GitHub) it would be worth trying.  Can you share a tree that suffers from the problem?  Or a minimal version that does?

[Thomas Passin]

I see where the problem is - or at least a problem - is, and it's serious. The problem I see is that when an outline with clones is re-opened, the clones are no longer clones.  This did not happen when I created some clones in my Workbook, so there are some conditions yet to be determined. I'll experiment some more to try to pin it down.  The outline which showed the problem had both an @auto-md and an @clean tree.  I'll try outlines with them separately and report back.

[Thomas Passin]

The loss of clones is specific to @auto-md trees (although I have not tested other @auto-xx trees):

In an outline with both @clean and an @auto-md trees, when the outline is closed and re-opened, the clone nodes of the @clean tree remained but the clone nodes of the @auto-md tree were no longer clones.

I don't know what the original intention was with respect to @auto-md trees, but this seems like a serious bug to me.  I'll create an issue for it.

[Thomas Passin]

The GitHub issue is 3355.

[Thomas Passin]

It turns out that this clone issue was discussed several years ago and I had completely forgotten about it, maybe because I haven't used @auto-xxx nodes or @presistence nodes.   See https://groups.google.com/g/leo-editor/c/oKGhRhUVTXA/m/xqUHMJzWAQAJ (thank you LewisNeal). But perhaps this is not the issue the OP has been encountering? 

[p.os...@datec.at]

Thanks a lot!

As for the loss of "cloneness" upon opening the file: I had this as well and got a hint here in this group (IIRC). Now the clones keep being clones and my Leo file has a node "@persistence" not added by me, but automatically somehow.

[p.os...@datec.at]

Again it happended. But now it happoend with vanilla nodes, as I replaced all clones by copies of the respective nodes. A section is cut off at

```bash

which becomes a node title. This node's body contains then all the sub nodes of the respective Leo tree.

What I need is an @auto-md that does not read, which for me makes no sense anyway: The content is in my Leo tree and should just be written into an MD-file, that will be processed by mkdocs.

Cheers

Paul

[Thomas Passin]

If you can, would you please post the offending outline.  Otherwise, if you can create a misbehaving example, please post that.

I've not worked with @auto-xx files and the only thing I know is that when the file's tree is written, headings are inserted for the node headlines, indented to match the tree.  Presumably, when the external file is read again by Leo it would remove those inserted headlines and use the information to re-create the tree. Is something else supposed to happen as well? 

[Thomas Passin]

On Friday, June 2, 2023 at 3:05:51 AM UTC-4 p.os...@datec.at wrote:

Again it happended. But now it happoend with vanilla nodes, as I replaced all clones by copies of the respective nodes. A section is cut off at

```bash

which becomes a node title. This node's body contains then all the sub nodes of the respective Leo tree.

It looks to me that the MD importer is a little confused at this point.  The code that seems to be executing here during the import is

        elif in_code:
            if line.startswith("```"):
                in_code = False
            lines_dict[top.v].append(line)
        elif line.startswith("```"):
            in_code = True
            lines_dict[top.v].append(line)

This looks like it should handle the code right, but one would have to do some checking to see if that is in fact happening as expected.

 

What I need is an @auto-md that does not read, which for me makes no sense anyway: The content is in my Leo tree and should just be written into an MD-file, that will be processed by mkdocs.

That's how the rst3 command works.  The @rst  file tree isn't actually an external file.  The command writes the @rst tree to a file, but that file never gets imported again.  But I don't believe there is an equivalent command for markdown.  I think there should be.  That may not be trivial to write because the @rst3 command looks pretty complicated to me.

OTOH, it probably wouldn't be hard to write a script that writes a subtree to a file, converting the headlines into the right indent level headlines.  That's really what you want, isn't it?

[p.os...@datec.at]

Hm, for now it seems a wrong ```-clause (markdown) being the reason for all the hassle: Replaced all ```bash by ```sh.  I'll see if this holds for clones as well (have to intro them again).

[Thomas Passin]

You might try ```shell too.