Debugging continues. Good, if slow, progress yesterday: 1. cc.strip_sentinels now uses the @file write code to strip sentinels. This is *much* better than using the @auto write code: it guarantees that section references hare handled correctly during the conversion. The alternative would have been really bad: adding special case to the @auto code. A bullet dodged.
2. After quite a bit of noodling it finally became clear that the actual move code in vc.move_nodes_to_organizers is working correctly. The real problem (hard to see) was that the "work list" (vc.global_moved_node_list) was wrong: it should *not* contain already-existing children of existing organizers. This was the cause of duplicated children of class nodes. Doh! Btw, I'm going to change the name of the work list to vc.work_list. It's a name I can remember and it seems to me to be more descriptive. 3. And there are other subtle problems with the work list. Although we should move existing children of existing organizers, we *do* have to keep track of the current child index in such nodes, because existing organizers may have organizer nodes, and we have to put those (pseudo-bare) organizer in the correct sibling order. This is a special case I did not foresee. It will probably affect one or two helpers of vc.demote. It will be tricky to get right, but once things work they will work solidly. 4. Trial writes: Initially, when everything was buggy, it was good enough for vc.trial_write to write only headlines. Yesterday I changed that method so it writes the body text of each node. I'm not sure this is correct-there is a theorem to be stated and proved. Again, it's ok for initial debugging, but it is probably time to use the @auto write code (that was just disabled in another context) to create a string that is *guaranteed* to be identical to what the real trial_write will be later. 5. I finally got around to changing "self" to either "vc" or "cc", depending on class. For big classes, I think it's good to be made explicitly aware of the class with this kind of convention. YMMV, but this is a strong preference of mine. I should have learned by now to refrain from making time estimates, but it does seem like the project is in the endgame. Two notes: 1. The at-file-to-at-auto command is always enabled, regardless of the the new_auto switch. On my fairly slow laptop it takes about 20 sec. to handle leoGlobals.py, (incorrectly at present). As I write this, I realize I probably should add progress messages if individual stages take more than a second or so... 2. Error correction (restoring the newly-created @auto file to what it was before moving nodes) does not exist yet: it would obscure the problems that I want to see during debugging. 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 [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/leo-editor. For more options, visit https://groups.google.com/groups/opt_out.
