On Jan 23, 5:25 am, "Edward K. Ream" <[email protected]> wrote:
> Last night I began a new task, namely using the presence of an @all > directive in the (root node of) and external file to control whether > clones in the external file should override clones in other files. Yesterdays work killed tnodeLists. That is, Leo never writes tnodeLists to .leo files, and uses tnodeLists in .leo files only when reading @file nodes with old file-like sentinels. Leo always writes @file nodes with new thin-like sentinels. As a happy side effect, Leo never "auto-saves" the .leo file after reading a file. There is no need to rigidly enforce the synchronization between .leo files (containing tnodeLists) and external files that depend on those tnodeLists. I just found, presumably, the cause of the bug just reported that new nodes remain dirty after a save. There seems to have been an "unforced error" in c.setChanged. I disabled the logic that clears clears the dirty bits in all nodes with the bizarre comment that Leo no longer uses tnodeLists(!!) Must have been a brain spike. Anyway, I'm going think out loud here about what happens when clones in an external file conflict with other clones, either in an external file or in the .leo file. For external files, two similar methods can override node definitions in external files: at.createThinChild4 and v.fastAddLastChild. The former handles conflicting node definitions when reading external files; the latter handles conflicting node definitions when reading cached files. Similarly, fileCommands.createSaxVnode overrides node definitions when reading .leo files. As I write this, I see that createSaxVnode doesn't check to see whether latter definitions of a node are compatible with former definitions. One would think that mismatches here would be serious. After all, we don't expect inconsistencies within the same .leo file. But I may be mistaken about this: perhaps some definitions are empty and other not, for example. However, the task at hand involves, presumably, at.createThinChild4 and v.fastAddLastChild. We want conflicting nodes in @auto trees to have low priority. This should be easy for at.createThinChild4. As I mentioned in the original post, at.readStartAll can set a flag. If this flag is set, at.createThinChild4 will defer to the previous definition, probably with a warning. The more interesting case involves v.fastAddLastChild. How can it know that the cached file contains an @all directive? I think it fair to assume that @all directives must appear in the root node of the tree that creates an external file. This has not been an explicit requirement so far, but it makes sense and it does, in fact, appear in the root node of all files that I use. Only v.createOutlineFromCacheList calls v.fastAddLastChild, and v.createOutlineFromCacheList calls itself recursively to populate the tree. A simple change will allow v.createOutlineFromCacheList to know whether it was called from itself or not. If not, it is creating the top-level node, so it can scan the body text of that node or @all directives. Actually, we could allow @all directives in any cached node. v.createOutlineFromCacheList could set an argument telling whether @all is in effect for the recursive call. As I write this, I realize this is an easy problem. Rather than having v.createOutlineFromCacheList scan all nodes for @all directives, I think only the topmost call should do the scan. We really do want this method to be fast. So that should be it. Both at.createThinChild4 and v.fastAddLastChild should warn about over-ridden node contents in similar ways. It remains to be seen whether fc.createSaxVnode should issue an "internal Leo error" when nodes collide. I expect this work to be done today. It had better be done today: with all the recent changes we will need until Friday to have any confidence that the b2 release will be stable. Edward P.S. I don't think Leo should auto-save the .leo file when clones collide. Marking the .leo file as changed should be good enough. 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.
