A problem with @button write-leoPyRef

[Edward K. Ream]

There is an ongoing problem with the script `@button write-leoPyRef`.

Iirc, this script is intended to be run from a dev's local leoPy.leo file.

There is a big glitch. After running this script Leo's git-diff command reports minimal changes, but actually loading and saving LeoPyRef.leo creates huge diffs as far as git itself is concerned.

I'm not sure what to do about this. Rev be3e404c in devel contains what I think is the latest version of LeoPyRef.leo, with the big diff.  This "round trips" properly: loading and saving LeoPyRef.leo creates a "null" diff (except for whitespace.)

Summary

My inclination is to leave everything alone for now, with the understanding that the new procedure should be:

- Run @button write-leoPyRef.

- Use Leo's git-diff command to check the "logical" diffs, ignoring node placement.

- Load LeoPyRef.leo and save same.

- Use the actual git-diff to double check the "real" diffs, which should be minimal.

- Commit LeoPyRef.leo if there is a non-trivial real diff.

Your comments, please.

Edward

[Thomas Passin]

I'm confused about leoPy.leo vs LeoPyRef.leo.  Some time ago, things were changed so that opening leoPy from the File/Open Specific Leo File menu actually opened LeoPyRef.  There is no leoPy.leo in the leo/core directory any more.  Looking through the write-leoPyRef, I infer that we are expected to create a leoPy.leo outline - presumably by saving LeoPyRef by that name, doing all our work in leoPy, then using the write-leoPyRef command.  Is that the idea?

Why isn't it OK to just work with LeoPyRef, and avoid all the headaches of diffs because of changed gnxs, etc?

[Edward K. Ream]

On Tue, Sep 20, 2022 at 11:29 AM Thomas Passin <tbp1...@gmail.com> wrote:

Looking through the write-leoPyRef, I infer that we are expected to create a leoPy.leo outline - presumably by saving LeoPyRef by that name, doing all our work in leoPy, then using the write-leoPyRef command.  Is that the idea?

Yes.

Why isn't it OK to just work with LeoPyRef, and avoid all the headaches of diffs because of changed gnxs, etc?

gnx's aren't a big problem.

What we want is to avoid git merge problems with LeoPyRef.leo.  Local copies (leoPy.leo) should avoid most git conflicts.

Edward

[Thomas Passin]

I'm missing some essential piece of understanding, I think.

1. I work on an existing external file (this is mostly what I have done).  This probably won't change LeoPyRef.  I commit the changed external file but don't commit LeoPyRef.  I don't see this as needing a leoPy.leo outline at all.

2. I want to add a new directory, probably with some new external files in it.  I make the changes to LeoPyRef and to my local worktree.  I commit the new directory and files, and also LeoPyRef.  What problems would this create that would be avoided by going through leoPy?

3. I want to add a new file to the existing directory tree;  perhaps it's a new plugin, perhaps it's a new language mode file.  I commit the new file, and I add a new subtree for it to LeoPyRef and commit that.  How will that create possible merge problems that would be avoided by making a new LeoPyRef outline from an intermediate leoPy outline?

I can see that there could be difficulties when one is working in one branch and makes changes to LeoPyRef as well as changes to external files;  and then before the PR for that is merged, some other PR rom another branch with other changes to LeoPyRef gets merged.  What I don't see is how making changes in a leoPy outline and writing a new LeoPyRef outline from it will help with this situation.  Either way, you end up with a PR that has changes to LeoPyRef that need to be reconciled with some other PR's changes.

[Edward K. Ream]

On Tue, Sep 20, 2022 at 11:52 AM Thomas Passin <tbp1...@gmail.com> wrote:

I'm missing some essential piece of understanding, I think.

1. I work on an existing external file (this is mostly what I have done).  This probably won't change LeoPyRef.  I commit the changed external file but don't commit LeoPyRef.  I don't see this as needing a leoPy.leo outline at all.

2. I want to add a new directory, probably with some new external files in it.  I make the changes to LeoPyRef and to my local worktree.  I commit the new directory and files, and also LeoPyRef.  What problems would this create that would be avoided by going through leoPy?

3. I want to add a new file to the existing directory tree;  perhaps it's a new plugin, perhaps it's a new language mode file.  I commit the new file, and I add a new subtree for it to LeoPyRef and commit that.  How will that create possible merge problems that would be avoided by making a new LeoPyRef outline from an intermediate leoPy outline?

I can see that there could be difficulties when one is working in one branch and makes changes to LeoPyRef as well as changes to external files;  and then before the PR for that is merged, some other PR rom another branch with other changes to LeoPyRef gets merged.  What I don't see is how making changes in a leoPy outline and writing a new LeoPyRef outline from it will help with this situation.  Either way, you end up with a PR that has changes to LeoPyRef that need to be reconciled with some other PR's changes.

In practice, only a few devs mess with LeoPyRef.leo, so the suggested workflow seems to make sense, but can't guarantee the workflow is a big improvement.

Edward