Please test the bug-1451 branch with --trace=save

[Edward K. Ream]

For those troubled by this bug, please check out the "bug-1451" branch and run Leo with --trace=save enabled.  This will tell you (in the console) what at.findFilesToWrite thinks should be written, and why.

Please let me know what, if anything, you see when Leo fails to write an @clean file as expected.

Edward

P. S. I can't duplicate this bug.  I have taken a close look at all the code and can find nothing amiss re #1451.  This proves nothing ;-)

Clearly, something strange is going on. It's particularly strange that using @nosent should work when @clean doesn't, because exactly the same write code is used for both!

EKR

[gar]

Hello. Was away for weekend.

Starting to use the branch. Let's observe for some days...

сб, 7 дек. 2019 г. в 16:35, Edward K. Ream <edre...@gmail.com>:

--
You received this message because you are subscribed to the Google Groups "leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email to leo-editor+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/leo-editor/9f540b14-1177-4d63-ae04-6781ba0f2440%40googlegroups.com.

[gar]

Caught it again. The complete scenario:

- small html file with @others

- one of the @other is for css

- tweaking one of the value, this looks like 'write a couple of symbols, save, ctrl-z, save, ...'

after one of the ctrl-z the changes were not saved.

 

пн, 9 дек. 2019 г. в 16:58, gar <gar...@gmail.com>:

[Edward K. Ream]

On Tue, Dec 10, 2019 at 1:25 AM gar <gar...@gmail.com> wrote:

Caught it again. The complete scenario:

- small html file with @others

- one of the @other is for css

- tweaking one of the value, this looks like 'write a couple of symbols, save, ctrl-z, save, ...'

after one of the ctrl-z the changes were not saved.

Thanks.  This is a good clue.

Edward

[gar]

Edward, everything is even worse when it looked like.

I met the following:

- I introduce a new pieces of code into @clean .html

- then I decide to get rid of it, so I do git reset and then open/close .leo file to apply the changes

- leo shows me that my changes are now gone

- ok, hitting 'enter' and then ctrl-c, see the log message 'wrote: ...html'

- reloading the page in the browser, going to the source and seeing that file remained untouched

- and since that I cannot force leo to write file w/o those changes, it says that it writes it - but the content remains the same

ср, 11 дек. 2019 г. в 02:44, Edward K. Ream <edre...@gmail.com>:

--

You received this message because you are subscribed to the Google Groups "leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email to leo-editor+...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/leo-editor/CAMF8tS0k_bm140YbgeqeAFq%2BbLFPcw82Zk%2BHp7ktzCQUbjgxxA%40mail.gmail.com.

[gar]

and yes, git shows me that the changes I have just resetted are again in the file

ср, 11 дек. 2019 г. в 07:52, gar <gar...@gmail.com>:

[gar]

the only thing helped is to totally delete the @clean ..html from filesystem, reload .leo project, make some changes into arbitrary outline and then save.

only in this case leo regenerated the file.

w/o changes leo didnt see that file is missing and didnt try to write it.

ср, 11 дек. 2019 г. в 07:53, gar <gar...@gmail.com>:

[gar]

Looks like that ctrl-z causes this odd behavior.

[gar]

I got an idea what's going on.

I close the outline. Then remove all changes with git. Then load back the outline w/o restarting leo.

When I hit ctrl-z - leo somehow restores the content of the outline before changes were resetted and undos them.

So I see all resetted changes again.

Unfortunately I cannot check it now - it stopped to happen for now.

[Edward K. Ream]

On Wed, Dec 11, 2019 at 3:24 AM gar <gar...@gmail.com> wrote:

Looks like that ctrl-z causes this odd behavior.

Thanks for this testing.

I distinctly remember there was a discussion that ctrl-z should reset the changed status of an outline. I can't seem to find the discussion or any changed code.

My present thinking is that undo should always set the outline's changed flag and in addition should mark all relevant nodes as dirty, rather than resetting their dirty bits.  Indeed, after saving a file, any change, including an undo, must set the dirty bits, else a later save will not see the changes.

Summary

Undo must set the dirty bits of all affected nodes, not restore/clear dirty bits.

I suspect there were recent changes in this area in response to a user's request.  However, I can find neither the corresponding issue nor corresponding changes in the code.

I'll continue my investigations.  This bug has top priority.

Edward