On Dec 17, 10:14 am, "Edward K. Ream" <[email protected]> wrote:
> In any case, it now appears that the tree drawing code, far from being > straightforward, shows where the deep problems lie. Those problems > necessarily will involve positions, iterators, and the related > position methods that traverse the tree, especially p.threadNext. There is an easy way to avoid remembering expansion states. The Aha is that we only must care about the expansion states of positions that are direct ancestors of the present position. We could contract all other nodes! This will solve the problem. p.isExpanded will return True if and only if p is an ancestor of c.currentPosition() ! Alas, contracting all off-main-line tree items is a brute force approach. I'd like to be more flexible than that. Maybe we can use the expansion bits in vnodes to expand a node when doing so won't draw "too much". Details entirely foggy at present. Changing p.isExpanded would be a major change to Leo. The Aha only gives an existence proof that Leo's outline can be drawn without looping. It's probably time to start thinking about what p.visNext means... Edward P.S. Starting Saturday I should be taking morning walks on the Naples beach. These vacation walks have typically been the source of inspiration. It appears that this year will be an especially good time for these walks. 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 -~----------~----~----~----~------~----~------~--~---
