On Thu, Nov 9, 2017 at 9:59 AM, Edward K. Ream <[email protected]> wrote:
Imo, the problem is a fairly straightforward bug in in at.writeAll. > Indeed, this method suppresses writes of any @<file> node p if p.v has > already been written. The "seen" set contains all previously-written > vnodes. > > But this test fails if p.v refers to two different paths. It looks like > the "seen" set should contain tuples (p.v, path) where path is the full > path to the to-be-written file. > > I'll attempt a fix immediately. > Rev a627fcc ensures that @cloned nodes to two different paths will both be written. The fix was entirely straightforward and all unit tests pass. But... *Warning* This rev changes corresponding code in at.readAll, but here the results are kinda like rearranging chairs on the Titanic :-) All will be well as long as both external files contain exactly the same code, but Leo does not detect if the two files are different, say if one has been changed with another editor. Afaik, Leo has *never *been able to detect changes between two different *cloned *nodes with the same gnx. What will happen is that one of the clones will "win". Before today, the *first* read node will win. Now, the *last* cloned node will win. In short, you are asking for trouble using two cloned @clean nodes (or any other kind of @<file> node). This has always been true, and will likely remain so forever. Edward -- 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 [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/leo-editor. For more options, visit https://groups.google.com/d/optout.
