On Wed, Jan 29, 2014 at 8:25 AM, Edward K. Ream <[email protected]> wrote:
The plan now is straightforward: Ignore the documentation, create minimal > tests that illustrate the bugs, get traces that illustrate the bugs, fix > the bugs ;-) Refactoring code that manipulates the anchors dict may help > with traces. > This worked well for the first few bugs ;-) When I awoke this morning several larger issues appeared: 1. The entire enterprise depends upon the quality of the @auto importers. I am far from satisfied with the present Python importer. This is not a fundamental problem, but it will require work. One or more new options will allow people can tailor the contents of imported nodes to their taste. 2. Just as with @shadow, there is an edge case that makes it impossible, in principle, to guess which (if any) of two organizer nodes should receive a node added outside of Leo. Just as with @shadow, the choice will not (or rather *should* not) affect the trial write, that is, the ultimate result when the @auto tree is written. But there is one situation in which the choice *does* affect the trial write. Suppose the new node appears just after the last node of a class. If the new node is indented as with the class's methods, it must be made part of the (existing) organizer node for the class. Otherwise, it should be "promoted" to a higher level organizer, if any. This special case will probably require a new method of the baseScannerClass, say, shouldBePartOfClass(theClassNode). In Python, the method will examine indentation and (maybe) the first argument (to see if it is "self"). In C++, the method would presumably look for theClassName::theFunctionName in the signature. In languages such as HTML the method will probably never be called, and if called its returned value would likely be irrelevant. 3. This kind of edge case can not (or rather *should* not ;-) appear when using the at-file-to-at-auto command because no nodes have actually been added. Alas, a similar kind of problem *does* arise in some situations when using at-file-to-at-auto. If a node (in the @file tree) contain trailing material following an class definition, the present code has difficulty placing the trailing material correctly. I'm *guessing* that what happens is that the code that creates the @auto-views tree "assigns" the trailing code to an organizer that won't actually be created, which ends up misplacing the node. Whatever the actual cause of this bug, it points up troubles with knowing exactly when to leave organizers, which is a problem akin to problem 2. I am tempted to consider a prepass that would "regularize" the @file tree *before* creating the @auto-view node. This might help, but it would require the cooperation of yet another helper of baseScannerClass. ===== Summary 1. Whatever happens, the @auto importers must be improved, especially the Python importer. The at-file-to-at-auto command will be run (conceptually) only once; the @auto importers are run every time the @auto file changes. The outline produced by @auto must be approximately as flexible as @file outlines. Otherwise, no one will enjoy the experience. 2. There are several other problems at present with at-file-to-at-auto. Imo, these are secondary considerations. In fact, the new @auto project could succeed even if at-file-to-at-auto fails. Having said that, I think everything can be made to work. The plan is this: 1. Regularize (by hand) the large test file I have been using, a copy of leoGlobals.py. This will show what can at-file-to-at-auto can do in the best case (assuming remaining bugs are fixed). 2. Improve the Python @auto importer so that it meets my minimum standards. This will show whether I could be happy using the new @auto scheme. 3. Assuming points 1 and 2 go well, do whatever it takes to complete the project. 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.
