About the default behavior for externally modifying a .leo file while it's opened in Leo

[Félix]

Have'nt change any settigns from default install...

Leo does not seem to react to having it's ".leo" file modified while it's opened. Is this the default//desired behavior? Is this new from some recent versions of Leo?

Thanks for any insights on this subject! 

--

Félix

[Edward K. Ream]

On Sun, Dec 6, 2020 at 3:21 PM Félix <felix...@gmail.com> wrote:

 

> Leo does not seem to react to having it's ".leo" file modified while it's opened.

I guess you mean, having an opened .leo file modified by another program.

Is #1240 what you mean?

Leo does continually monitor changes to external files, and raises an alert when that happens.

Does this clarify matters?

Edward

[tbp1...@gmail.com]

No, I don't think that's what Félix means.  Open a .Leo file in say a text editor while it's also open in Leo.  In the text editor, make a change to the .leo file and save.  Leo doesn't notice the change.  I just tried it. After I closed and reopened the .leo file in Leo, the change showed up in Leo, but Leo hadn't known about it before the re-opening.

Félix, is that what you mean?

TomP

[Edward K. Ream]

On Sun, Dec 6, 2020 at 8:34 PM tbp1...@gmail.com <tbp1...@gmail.com> wrote:

No, I don't think that's what Félix means.  Open a .Leo file in say a text editor while it's also open in Leo.  In the text editor, make a change to the .leo file and save.  Leo doesn't notice the change.  I just tried it. After I closed and reopened the .leo file in Leo, the change showed up in Leo, but Leo hadn't known about it before the re-opening.

Félix, is that what you mean?

Hehe. What you just said is what I thought Félix meant :-)

It will probably be easy to have Leo notice changes to .leo files (while Leo is running).

Edward

[Edward K. Ream]

On Monday, December 7, 2020 at 5:32:43 AM UTC-6 Edward K. Ream wrote:

It will probably be easy to have Leo notice changes to .leo files (while Leo is running).

Done at rev  d501d5 in the ekr-change branch.  See #1240 and PR #1771.

Edward

[Félix]

Thank you to both of you ! I'll take a look at this again tonight :)

--

Félix

[Edward K. Ream]

On Mon, Dec 7, 2020 at 8:46 AM Félix <felix...@gmail.com> wrote:

Thank you to both of you ! I'll take a look at this again tonight :)

You're welcome. Is this important for leoInteg?

Edward

[Félix]

Not directly used by leoInteg,  but the behavior should be mimicked by leointeg: I want to make sure leoInteg does it too (I removed this when making the auto-detection/auto-answer of derived files part of leoInteg - I should have let it in for .leo files themselves too!) 

I guess this is very important when switching git branches: the .leo file has to refresh everything including itself first!

hehehe ... but don't worry, my roadmap is still : 

1- fix body pane

2- official release on extention market

3- .leo dirty file detection and refresh along with all other pending issues :)

--

Félix

[jkn]

Can you explain the new behavior a bit more? I am not very clear about the differences

between #1240 and #1771.

I have asked for something like this in the past, but (perhaps because I haven't explained it

well enough) Edward thought it was done. I would like to know we are talking about the same thing(s)

Thanks, J^n

[Edward K. Ream]

On Mon, Dec 7, 2020 at 9:56 AM Félix <felix...@gmail.com> wrote:

Not directly used by leoInteg,  but the behavior should be mimicked by leointeg: I want to make sure leoInteg does it too (I removed this when making the auto-detection/auto-answer of derived files part of leoInteg - I should have let it in for .leo files themselves too!) 

I guess this is very important when switching git branches: the .leo file has to refresh everything including itself first!

OMG. Why didn't I think of this before??

This issue, #1240, should solve #1183, which I had marked "Can't Fix"!

Edward

[Edward K. Ream]

On Mon, Dec 7, 2020 at 10:53 AM jkn <jkn...@nicorp.f9.co.uk> wrote:

> I am not very clear about the differences between #1240 and #1771.

#1240 is an old issue. It may have been inspired by your request, but I don't have any memories. #1771 is simply the corresponding pull request.

There are subtle, useful, differences between the descriptions (first comments) of issues and pull requests. Pull requests are oriented towards diffs. The corresponding issue is focused more on the big picture. But this varies according to circumstance.

Does this make sense?

Edward

[jkn]

Hi Edward

    your explanation of the difference between #1240 and #1771 does, thanks. I think my issue is unrelated to any recent insights re. git branches etc.

I have tried the smallest example I could to illustrate what behaviour I see, and hope for. This is on:

Leo 6.4-devel, devel branch, build 30ca7ea314
2020-12-05 09:26:07 -0600
Python 3.6.9, PyQt version 5.9.5
linux

Steps:

1) In leo, create a new outline, say with a couple of nodes. save as myfile.leo.

2) keeping in leo, switch to a console, say. Edit the leo file  (or just 'touch' it) in a text editor, save & exit

3) switch focus back to leo

4a) hoped for/expected: Leo notices the change and says "do you want me to reload the file into Leo?"

4b) observed: leo does not notice the change (yet)

4c) observed: if I then (or, later, after some leo editing activity) try to save the file in Leo, the fact that the underlying file has changed *is* noticed. I get a dialog box:

    dialog title: "Overwrite the version in Leo": dialog text: "<myfile.leo> has changed in leo\n Overwrite it?"

4d) observation: regardless, the text of this dialog is confusing.

I guess there are two non-usual situations here:

A) When acquiring focus (or through periodic checks), Leo notices that the file on disk has been changed somehow. It asks whether I want to reload the new file into Leo

B) before attempting to write the file, Leo notices that there is a discrepancy. It asks for confirmation whether I want to overwrite the file on disk

I would expect (A) to be the most usual/useful case; Leo currently seems to try for (B)

Does that help/make sense?

    thanks

    Jon N

[Edward K. Ream]

On Thu, Dec 10, 2020 at 2:08 PM jkn <jkn...@nicorp.f9.co.uk> wrote:

Hi Edward

    your explanation of the difference between #1240 and #1771 does, thanks. I think my issue is unrelated to any recent insights re. git branches etc.

I have tried the smallest example I could to illustrate what behaviour I see, and hope for. This is on:

Leo 6.4-devel, devel branch, build 30ca7ea314
2020-12-05 09:26:07 -0600
Python 3.6.9, PyQt version 5.9.5
linux

The ekr-change branch contains the work. See PR #1771. I'll merge the branch into devel later today or tomorrow.

Edward

[jkn]

OK, I'll give that branch a try. I think I was confused because the comments on #1240 did not seem to indicate recent substantive work (ie. in a none-devel branch).

Thanks, Jon

[jkn]

update, after trying with the ekr-change branch:

- making a change in the .leo file (outside of leo) now seems to be noted. I still think the dialog text is confusing though. To my mind 'overwrite it' smacks of writing something to disc, and the wording should be more like ... reload into Leo?"

- just touching the file (ie changing the timestamp) externally doesn't seem to be noticed by leo, at least not consistently.

- Leo also fails to restart sometimes after answering 'yes'

    HTH

    Jon

[Edward K. Ream]

On Thu, Dec 10, 2020 at 4:17 PM jkn <jkn...@nicorp.f9.co.uk> wrote:

update, after trying with the ekr-change branch:

- making a change in the .leo file (outside of leo) now seems to be noted. I still think the dialog text is confusing though. To my mind 'overwrite it' smacks of writing something to disc, and the wording should be more like ... reload into Leo?"

I'll change the dialog.

- just touching the file (ie changing the timestamp) externally doesn't seem to be noticed by leo, at least not consistently.

That's on purpose. efc.has_changed first checks the timestamps. If they are different, the code then checks that the contents are different. Only then does it raise the dialog.

- Leo also fails to restart sometimes after answering 'yes'

I'll look into this.

efc.ask does have some weird timing code, which is probably needed because the dialog is raised as the result of checks that are made periodically at idle time.

Edward

[jkn]

On Thursday, December 10, 2020 at 11:50:39 PM UTC Edward K. Ream wrote:

On Thu, Dec 10, 2020 at 4:17 PM jkn <jkn...@nicorp.f9.co.uk> wrote:

update, after trying with the ekr-change branch:

- making a change in the .leo file (outside of leo) now seems to be noted. I still think the dialog text is confusing though. To my mind 'overwrite it' smacks of writing something to disc, and the wording should be more like ... reload into Leo?"

I'll change the dialog.

Thanks!

 

- just touching the file (ie changing the timestamp) externally doesn't seem to be noticed by leo, at least not consistently.

That's on purpose. efc.has_changed first checks the timestamps. If they are different, the code then checks that the contents are different. Only then does it raise the dialog.

I thought that might be the case ... understood

 

- Leo also fails to restart sometimes after answering 'yes'

I'll look into this.

efc.ask does have some weird timing code, which is probably needed because the dialog is raised as the result of checks that are made periodically at idle time.

Yes, I appreciate that. Thanks for your continuing work on this

    Jon N

[Edward K. Ream]

On Fri, Dec 11, 2020 at 2:07 AM jkn <jkn...@nicorp.f9.co.uk> wrote:

 

>>>Leo also fails to restart sometimes after answering 'yes'

>> I'll look into [the restart issue].

> Yes, I appreciate that. Thanks for your continuing work on this

You're welcome. I had planned to merge the ekr-change branch into devel today, but I'll put that on hold while I investigate the restart part of the issue.

Edward

[Edward K. Ream]

On Friday, December 11, 2020 at 5:54:50 AM UTC-6 Edward K. Ream wrote:

I had planned to merge the ekr-change branch into devel today, but I'll put that on hold while I investigate the restart part of the issue.

The fix, I think, is now in the ekr-change branch. Please test that branch and report any further problems.

Edward

[jkn]

Sorry, I missed this. I'll try it soon.

I came here to say that I have noticed that (eg) Firefox recently failed to restart, after it updated itself and told me it needed to do so. I mention this just in case there is something particular to my system ... but in any case, at least you are in good company!

    J^n