The following are notes to myself, and to future maintainers. Feel free to ignore.
The g.new_config switch is a bit misnamed. It embodies two inextricably "entwined" projects: the simplification of c.config.get, and the simplification of the complex code needed to read local files *twice*. The first read discovers settings, the second read uses those settings to open the file. The first read always uses a null gui; the second read uses g.app.gui, whatever that happens to be. After yesterday's work (not upped yet) Leo works regardless of the g.new_config switch. Yesterday's code was an experiment, and it produced truly ugly code. I'll rewrite it today. I haven't done all the recent code cleaning to settle for junk! The new_config code is now at what could be called a base camp. Here is my plan for reaching the summit of correct, clean code: 1. It's time to move the code in g.openWithFileName into the LoadManager class, say LM.openLocalFile. This will allow simplifying refactorings to be done entirely in the LM. g.openWithFileName will do nothing but call LM.openLocalFile. I'm not sure what making g.openWithFileName "reentrant" means, but if it can be done, it can be done in LM.openLocalFile. 2. LM.openLocalFile will embody all aspects of the complex strategy necessary for opening a local file twice. LM.openLocalFile will call a helper method twice, once for the pre-read and once for the final read. Let's call this helper LM.openFileByName. LM.openFileByName will contain almost all of the code presently contained in g.openWithFileName, with the crucial simplification that it will open the file only once. That is, LM.openFileByName will never do a pre-read; it simply opens the file **using whatever settings are in effect**. This, at last, is a clean design. 3. This morning, as I awoke, I realized that LM.openFileByName must work even if *no* settings files have ever been read. This will almost never happen, but this is an important test of the logical coherence of the plan. I'll probably add a LM switch to test this condition. This condition is important because the load process *creates* some Commander ivars and then almost immediately *uses* those ivars. Yesterday a (fortuitous) bug in the experimental code raised an AttributeError for one of those ivars. The LoadManager must ensure that such AttributeErrors never happen. 4. We come now to the topic that has bedeviled Leo's startup code from the very beginning, namely how to "give" the settings discovered in the *first* read to the c.config objected created in the *second* read. Yesterday's experimental code attempted to do that inside g.openWithFileName. The results were horrendous. This approach has no chance of working cleanly, which is why I am writing this post :-) In the new scheme, all the ugly experimental code will disappear. LM.openLocalFile, *not* LM.openFileByName, will "hand off" config settings as follows... Let c1 and c2 be the commanders returned by the first and second calls to LM.openFileByName. After the first call to LM.openFileByName, the c1.config object contains two dicts that must be passed to the c2.config object created by the *second* call to LM.openFileByName. We'll pass this information using a new keyword argument of LM.openFileByName, say previousSettings. The previousSettings keyword argument will be an object of a new helper class, LM.PreviousSettings, containing c1.config.settingsDict and c1.config.shortcutsDict. Formerly, I would have used a g.bunch, but imo it's better to create a formal identity for this vital information. The second call to LM.openFileByName will pass the previousSettings object to the Commander ctor that creates c2, which in turn will pass the previousSettings object to the c2.config ctor. Hurray! The c1 settings have been passed to c2.config! This is much cleaner than setting global LM ivars, which is what the experimental code did. Because of the previousSettings object, the second call to LM.openFileByName does *not* need to "synthesize" a link to c1 using c.hash. This stamps out bug 568452 at its source. Furthermore, the new code might allow the GC to recycle c1 and its frame when LM.openLocalFile completes. That's about it. A gotcha might still be lurking somewhere, but this plan looks simple enough to work. At long last there is a *clear* way forward. Edward -- 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.
