Leo 5.7.2 released

Leo 5.7.2, http://leoeditor.com, is now available on GitHub . Leo is an IDE, outliner and PIM, as described here . *The highlights of Leo 5.7.2* - Much improved support for Jupyter (.ipynb) files. - Fixed

Re: ENB: Fixing clone problems

On Monday, May 7, 2018 at 7:31:09 AM UTC-5, Edward K. Ream wrote: For now, we can live with the possibility that checkForChangedNodes will > issue a structure warning. > I see three ways to complete the code: 1. Leave the code as it is. 2. Remove the try/except block, and just have Leo crash

Re: ENB: Fixing clone problems

On Monday, May 7, 2018 at 10:02:31 AM UTC-5, Terry Brown wrote: > > On Mon, 7 May 2018 08:10:49 -0500 > "Edward K. Ream" wrote: > > > Unless other problems arise we'll make this part of 5.7.3. Imo, the > > buggy legacy code is good enough for master & 5.7.2 branches

Re: ENB: Fixing clone problems

On Mon, 7 May 2018 08:10:49 -0500 "Edward K. Ream" wrote: > Unless other problems arise we'll make this part of 5.7.3. Imo, the > buggy legacy code is good enough for master & 5.7.2 branches because > devs will be using devel. Haven't been following this thread in detail,

Re: ENB: Fixing clone problems

On Mon, May 7, 2018 at 7:56 AM, vitalije wrote: > Ok, I have just tested the scenario you have suggested. > ​Thanks for these tests. They could be called a practical proof. Unless other problems arise we'll make this part of 5.7.3. Imo, the buggy legacy code is good

Re: ENB: Fixing clone problems

Ok, I have just tested the scenario you have suggested. First I have created new test branch. Then I have opened leo/core/LeoPy.leo using ea51c84c93bf version of Leo. I have inserted one organizer node in leo/doc/leoNotes.txt and movde two existing nodes to be children of this organizer node.

Re: ENB: Fixing clone problems

On Mon, May 7, 2018 at 7:21 AM, Edward K. Ream wrote: In this case I think a redundant check (a belts and suspenders approach) > may be warranted. > ​Let's proceed pragmatically. ​I'll officially appoint you, Vitalije, as Leo's caching master. I encourage you to simplify

Re: ENB: Fixing clone problems

On Mon, May 7, 2018 at 6:51 AM, vitalije wrote: This scheme should ensure that the structure of all nodes in the outline >> match the structure of corresponding nodes in external files. If they >> don't, the hashes will differ and the external file will be re-read. >> > >

Re: ENB: Fixing clone problems

> > 1. Each @ node will have a uA containing the sha1 hash of the file > when last written *from the outline*. > > 2. Leo do a full read of the file if the hash does match the value *in > the outline*. This check will be done regardless of the contents of the > cache and regardless of the

Re: ENB: Fixing clone problems

On Monday, May 7, 2018 at 1:47:35 PM UTC+2, Edward K. Ream wrote: > > > On Sun, May 6, 2018 at 9:01 AM, Edward K. Ream > wrote: > > This is an Engineering Notebook post related to #892: Crash in >> checkForChangedNodes when switching git branches >>

Re: ENB: Fixing clone problems

On Mon, May 7, 2018 at 6:46 AM, vitalije wrote: > >> What about computing the sha1 hash of the entire .leo file, in addition >> to the hashes of external files? If there is a mismatch, Leo would bypass >> the cache and reload all external files. >> >> Alas, this won't work.

Re: ENB: Fixing clone problems

On Sun, May 6, 2018 at 9:01 AM, Edward K. Ream wrote: This is an Engineering Notebook post related to #892: Crash in > checkForChangedNodes when switching git branches > > The problem isn't as hard as either Vitalije or

Re: ENB: Fixing clone problems

> > > What about computing the sha1 hash of the entire .leo file, in addition to > the hashes of external files? If there is a mismatch, Leo would bypass the > cache and reload all external files. > > Alas, this won't work. Or rather, Leo *already does this* when switching > branches. The

Re: Rev 139697564 (devel) adds leo_babel files to leoPluginsRef.leo and to leo/plugins

On Sun, May 6, 2018 at 6:57 PM, Segundo Bob wrote: > Your version of Leo-Babel in revision ea51c84 is fine with me and so far > as I can tell is fully functional. > ​Excellent. The I would suggest ignoring or deleting your babel-related branches. They have done their