On Thursday, January 30, 2014 8:48:41 AM UTC-5, Edward K. Ream wrote:
> 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). > I'm glad I started with this step. Although it took considerable time, it revealed that the existing @auto can already do a good job. Here are the problems I encountered: 1. The at-file-to-at-auto command will fail if a node contains an entire class, rather than having each method be in a separate child node. The class node will not be handled properly when nodes are rearranged. Details don't matter here. The solution to this problem, and perhaps other problems, would be to do a pre-pass that ensures that all classes are fully "parsed" into child nodes. This can be done manually using the parse-body command, although it can fail. The pre-pass could, in essence, run the parse-body command as needed. Determining when it *is* needed would probably be a bit tricky. 2. Section references disappear, being replaced by the section definition. This is kinda ok for now, but I see no reason why the at-file-to-at-auto shouldn't add a comment that indicates where the reference originally appeared. Note that this comment will become part of the string passed to the @auto importers, so they won't cause any failures while checking trial writes. Indeed, I think @auto should *always* add section reference comments. They can't happen "by accident" (when importing someone *else's* external file, so why not allow them when the Leo user is the one to change the external file? These *plain* section reference comments are indistinguishable from any other comments., so should be *completely* unobjectionable. This is *not* a case of making an "innocent" change to a file; it is a case of making an ordinary change to a file. It will be acceptable if and only if changes are acceptable in general. 3. At present, the hardest problem seems to be organizing imports and other declarations that typically appear at the start of each file. Such things typically do not contain class or function defs, and there is no mechanism in place to signal to the @auto importers that separate nodes are desired. This is a surprisingly difficult problem, and I would hate to do without such "initial organizers". One possible solutions would allow 1-level section references. The entire definitions for such references would appear in a *single* node. The question still remains: how to get the @auto importers to recognize these nodes. A mystery, especially if even light sentinels are verboten. 4. An easier problem: Trailing assignments get moved to the wrong node. This can happen even if the perfect import check succeeds. This is very bad when multiple organizer nodes intervene. The solution is to have the importer add everything after the def until the start of the next class or def. The solution is local to the importers. A related issue: I prefer @bool at_auto_separate_non_def_nodes = False It may help the new @auto code to make this the default for at-file-to-at-auto. ===== Summary 1. A prepass will probably be needed to ensure that all nodes in the @file tree have the proper format. 2. No obvious solution exists so far for organizing initial declaration nodes. Some real invention will be required. 3. Relatively simple changes to the importers (maybe just the baseScannerClass code) may suffice to place trailing lines in the proper nodes. We shall see... This is good progress, even though no real code has been written today. 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.
