On Sat, Jan 28, 2012 at 11:49 AM, Edward K. Ream <[email protected]> wrote:
>> Next, I'll ensure that the key bug Terry recently mentioned has been stamped >> out... > > This bug relates to settings, but not 879331. I think I see what is causing problems with settings that disappear depending on exactly how the .leo files are described. Some of the configuration code uses c.hash() to associate settings with commanders. It's bad code, but we are stuck with it But c.hash probably doesn't work for all descriptions. Terry, you might try messing with c.hash to see if changing it makes a difference. In particular, you might trace the result returned in the various scenarios that have been giving you troubles. The new key code still doesn't work as I would like. The problem is that settings are read *twice* for local files, and it's not so easy to associate values read in the first pass with the values read in the second pass. In other words, c.config is different in the two passes because c is different. These kinds of bizarre considerations lead me to c.hash... Extreme patience is required for this work. I have added some important comments to methods like get and getShortcutHelper that indicate what the various (badly-named) dictionaries and lists come from and how they are used. So now I understand the code about as well as it *can* be understood :-) Looking back on the code, I can see that it arose as the result of 30+ years of procedure-oriented C coding. Theoretically, refactoring into new classes would help, but that's way too risky to do in one bite. So I'm stuck with making smallish changes for now... 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.
