Hi Edward, I am very thankful, too, that we can have this discussion and I really plan to dig deeper into Leo code once I'll be able, to be more helpful.
On Jan 12, 4:47 pm, "Edward K. Ream" <[email protected]> wrote: > On Jan 12, 6:45 am, "Edward K. Ream" <[email protected]> wrote: > > > perhaps you should dial back your usage of cross-file clones. To summarize my current situation, currently I don't use clones at all, and I restricted my project.leo to non-nested @shadow nodes, containing multi-level tree of <<sections>> and occassionally @others. Nothing else, yet I still get some "uncached read node changed" messages every time I am refreshing shadow nodes from changed external files. You are saying this is not OK? > I actually think this advice is the heart of the matter. My guess is > that you are using Leo's clones to try to overcome the limitations of > languages like html that lack functions. That's understandable, but > dangerous. > > Indeed, neither Leo nor any other program can possibly solve the > multiple update problem for arbitrary collections of external files. > Expecting Leo to do so is simply unreasonable, as I have said many > times before. > > I have also said many times before that cross-file clones are > inherently problematic. If you choose to be "creative" in this > regard, I believe it is up to *you* to demonstrate that your expected > work flow will not cause data loss as a result. There is simply no > way for Leo to do magic on your behalf. This is a fact of life, not a > bug in Leo per se. > > For example, leoPy.leo uses cross-file clones, but only in a > stereotyped manner. Clones appear either in leoPy.leo itself, or in > @file leoProjects.txt. This works because: > > 1. leoProjects.txt contains @all and > > 2. leoProjects.txt appears before all other @<file> nodes in > leoPy.leo. > > This combination ensures that changed code in an external file will > overwrite the clones in leoProjects.txt. > > Is this a perfect and robust scheme? No it is not. But it works > fairly well and is about the best that can be expected. > > HTH. > > Edward > > P.S. In your particular situation, I would suggest, if at all > possible, that you make complete external files, rather than clones, > to be the "units of sharing". That way there is only one copy of the > data, so if you change that data outside of Leo all clones of (parts > of) that data will be in synch the next time you open Leo. > > EKR -- You received this message because you are subscribed to the Google Groups "leo-editor" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/leo-editor?hl=en.
