On Fri, Jan 10, 2014 at 6:01 AM, Edward K. Ream <edream...@gmail.com>wrote:
> A few details remain to resolve. These could be called debugging items. > .. > > > The symptom of the bugs is that *non-bare* organizer nodes are not placed > in correct sibling order. > .. [The] f > undamental problem is that the code does not fully account for the outline > relationships between organizer nodes. > .. > These problems have been fixed! The new vc.compute_descendants method computes the set of descendants for each organizer node. As a result, the code now handles all organizer nodes properly. Furthermore, an amazingly useful new trace in vc.move_nodes (or rather its new helper, vc.move_nodes_to_organizers) now makes clear exactly what moves are *intended* to be moved where. (Actually moving them is another matter ;-) Alas, the project is not complete. I have forgotten an important part of the puzzle: Doh, there are *two* kinds of organizer nodes: - those that do *not* exist in the imported outline (these now work). - those that *do* exist in the imported outline. For example, I usually put the helpers of method X as children of X. There is *no way* for the read logic to recreate such nodes at present, because the parent/child relationships are do not exist in the @auto file. So X is an organizer node! Happily, it should be relatively straightforward to support **existing organizers**: 1. The write code will represent existing organizers with @existing-organizer: nodes rather than @organizer: nodes. As with @organizer: nodes, the headline will contain the headline of the organizer node; the body will be a list of unls. The write code can easily discover existing organizers: they are nodes with children that contain something other than comments and blank lines. 2. The read code will create OrganizerData entries for @existing-organizer nodes just as with @organizer: nodes. A new ivar, data.existing, will distinguish between @organizer: and @existing-organizer nodes. These new entries will be members of a new global list of all organizer nodes. The goal will be to confine tests of data.existing to the setup code. That way, all the hard code will continue to work as is. We shall see whether this is possible. 3. The code that munges unls will drop unls for a data object only if data.existing is False. This may be more tricky than it sounds. In any case, this is the fundamental reason why @existing-organizer: nodes *must* exist. 4. Two minor speedups are possible. Each seems (slightly) more important now that there are more organizer nodes to handle: - At present, vc.compute_tree structure is called in vc.demote_helper. It should be possible to call it just once. - vc.compute_descendants uses a iterative algorithm that is O(N**2) on the number of organizers. This really bothers me, although it is unlikely to be a real problem. An O(N) recursive algorithm may be possible. All this seems straightforward, but I won't be surprised if unforeseen complications are lurking. Once again, complete success seems at least a few hours away :-) Otoh, I am ever more confident that this project *will* succeed. 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 leo-editor+unsubscr...@googlegroups.com. To post to this group, send email to leo-editor@googlegroups.com. Visit this group at http://groups.google.com/group/leo-editor. For more options, visit https://groups.google.com/groups/opt_out.
