On Fri, May 14, 2010 at 3:22 PM, Terry Brown <[email protected]> wrote:
> I don't see how you could avoid accidentally deleting them... These same way you avoid deleting sentinels now. That is, sentinels would start with #@, so you know where they are. > On the numbers incrementing per .leo file gnx replacement... I guess there's > no way that can lead in increased gnx clashes, as there will be lots of .leo > files with gnx '1' out there. But I suppose as long as only leo moves the > nodes between files, this won't be a problem. The N for the .leo file would be max(N,n1,n2,...) where the ni are the max N in each external file. Given that, no new gnx can conflict with any data in either the .leo file or the external files. It's simple and foolproof. I'm definitely going to play with this. Switching from old-style to new-style gnx's will require a bit of care at load time. There will be dict whose keys are old gnx's and whose values are new-style gnx's. We must be sure to use this dict when allocating new gnx's so as to preserve clone links. But this is a routine complication. Edward P.S. The biggest payoff may actually be the elimination of closing sentinels for most nodes. This is in fact a completely separate issue. But unless I am forgetting some ancient gotcha, I think this should be possible. 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.
