On Sat, Aug 29, 2009 at 5:09 PM, Edward K. Ream<[email protected]> wrote:
> I'm a bit concerned that the caching data is a list of lists. That makes it > hard to extend the format of cached data. A dictionary whose entries might > be other dictionaries would be more flexible. Other data does not have to reside in the cached files - we can put it anywhere in c.db, keyed by gnx. In any case, if we want to change the cache format in the future, we can just change it - cached files do not have to remain compatible through leo versions. > At present, the expansion bits in <v> elements of a .leo file are not > handled properly, regardless of caching. I have a dim memory that that was > on purpose. But if, say, we did want to remember expansion bits inside > @thin trees, we would have no way to do so in the present caching scheme. I think we would. @thin files do not store the status anyway, and the cached file merely takes the place of external file. It has the exact same info as the external file, nohing more, nothing less. > I fixed the bug by having fast_add_last_child return the tuple > (is_clone,child). > > create_tree_at_vnode sets child.b,child.h = b,h if is_clone is True. > > This fix appears to work as expected. I'll push it later today after eating > my own dog food awhile. I'm a bit sceptical about this. I think you'd need to nuke the existing subtree of the clone and create a new subtree in its place. This may be what happens eventually though... > P.S. I moved the tree stuff out of leoGlobals.py into leoNodes.py. Great. -- Ville M. Vainio http://tinyurl.com/vainio --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
