Warning: Leo 6.8.6 does not always handle @clean properly

[Edward K. Ream]

Issue #4404 reports a critical bug that can cause data loss for @clean x.html and perhaps other file types. My apologies for the botch.

For those using @clean, the most prudent course of action may be to revert to Leo 6.8.5 for now.

Félix and I have isolated the bug to at.do_changed_vnode. Disabling that method solves the problem. This bug may be limited to languages such as html that lack functions. It may also be more general.

I plan to release Leo 6.8.7 in a week or so after Félix and thoroughly test the fix. Better unit tests are also needed.

Edward

[Edward K. Ream]

On Saturday, August 2, 2025 at 10:10:22 PM UTC-5 Edward K. Ream wrote:

Issue #4404 reports a critical bug that can cause data loss for @clean x.html and perhaps other file types. My apologies for the botch.

For those using @clean, the most prudent course of action may be to revert to Leo 6.8.5 for now.

Still true. I have yanked Leo 6.8.6 from pypi. `pip install leo` should now install Leo 6.8.5.

I have added a warning to the GitHub announcement of 6.8.6.

I plan to release Leo 6.8.7 in a week or so...

I shall release Leo 6.8.6.1 tomorrow. This release will delete all the buggy code. My idea of post-processing changed nodes seems headed for the dustbin of history. And that's a good thing :-)

Edward

[Félix]

Thanks for those quick fixes!

 Indeed 'exploding ' a node into a suboutline via it's importer logic should not be done in the @clean read logic, (because it "destroys" any custom outline construction already existing in the outline when a changed node is encountered by the read process and replaces it with an 'exploded suboutline' made by the @auto importer code for that specific file-type) that concept could be useful in some other circumstances...

Could that do_vchange_vnode code be salvaged and put into a command Instead of having it be part of the @clean read algorithm - in 6.8.7 or some later version?

So that after a refresh from disk is completed (or any other circumstances), could a user select a position that he wishes to get 'exploded into a sub-outline' with its appropriate importer logic based on the file extension via a command in the command palette?

(of course, if he selects a clone that is not the descendant of an @clean, the command should loop that clone's other instances to find one that is descendant of an @clean node, so that it's done on a position that is part of an @clean tree)

.... just a thought I had while eating breakfast this morning  :)

Félix

[Edward K. Ream]

On Sunday, August 3, 2025 at 12:00:26 PM UTC-5 Félix wrote:

Thanks for those quick fixes!

You're welcome. Our zoom discussions were invaluable. 

Indeed 'exploding ' a node into a suboutline via it's importer logic should not be done in the @clean read logic, (because it "destroys" any custom outline construction already existing in the outline when a changed node is encountered by the read process and replaces it with an 'exploded suboutline' made by the @auto importer code for that specific file-type) that concept could be useful in some other circumstances...

I don't believe the (now defunct) code typically did that. Happily, the question is moot. 

Could that do_vchange_vnode code be salvaged and put into a command Instead of having it be part of the @clean read algorithm - in 6.8.7 or some later version?

Maybe, if my life depended on it, but I would like to defer any heroic actions until somebody needs the improvements. We've gone a long time without any changes to @clean. Leo 6.8.6 drastically improves the performance of @clean. That's plenty good enough for me.

Edward