LeoPyRef is broken since October last year

[vitalije]

While working on python importer recently I've noticed strange behavior of the LeoPyRef.leo. If I just open this file using Leo and save it, I get a huge diff. I didn't have the time to investigate it further until now.

By bisecting, I've found that since the revision b7d66e100 (which was at the 18th Oct 2020) every committed version of LeoPyRef.leo has the same issue.

The commit b7d66e100 added a button write-leoPyRef and I assume that since then this file was saved using this button. I can't see why this script produces different result than ordinary c.save, but it does. The tnodes in the LeoPyRef.leo produced by this script are not sorted according the tx attribute, like when the file is saved using normal c.save.

This produced huge difference in this commit 8601 insertions and 680 deletions, and yet only one small script was added.

Unless tnodes are sorted, potentially every commit to this file can produce huge diffs.

Vitalije

[Félix]

Thanks for looking into this. I've once signaled this problem last year, and Edward fixed it - but it crept beck in at some point and indeed now this problem is back again. 

Thanks again also for finding out the way this could have happened ! 

--

Félix

[vitalije]

Fixed script write_LeoPyRef in in ecf7fe4c890bc. Now, LeoPyRef.leo has the same content no matter if it is saved from Leo or generated from write_LeoPyRef script.

[Edward K. Ream]

On Saturday, December 18, 2021 at 3:07:42 PM UTC-6 vitalije wrote:

Fixed script write_LeoPyRef in in ecf7fe4c890bc. Now, LeoPyRef.leo has the same content no matter if it is saved from Leo or generated from write_LeoPyRef script.

Many thanks for this. Rev df70415 in devel tests your changes by adding a comment in the script that put_tnodes is not the same as fc.putTnodes. The diffs were as expected, and no more :-)

Edward