Yesterday I took a detour in my quest to fix the key-related bug. Imo, this detour is essential, even though it may cause some temporary problems in the trunk. I doubt very much if creating a new branch would help in the long run: we may as well face the problems now.
Important: The following are notes to myself. Feel free to ignore this post. The essential problem is that the settings-related code in leoConfig.py and (to a lesser extent) leoKeys.py is a patched-up mess. There are reasons for this mess, but it's time to attempt a cleanup. The *symptom* of the mess are various uses of g.Bunch objects within leoConfig.py and leoKeys.py. The g.Bunch class is a kind of catch-all that allows g.Bunch objects to have whatever ivars are specified when creating the g.Bunch. There are times, I suppose, when using g.Bunch objects is relatively unobjectionable, but for complex code using g.Bunch objects seems simply wrong. I have often said that we Python programmers act *as if* we knew the types of our objects, but this statement breaks down completely when using g.Bunch objects. Indeed, using a g.Bunch is equivalent to using unconstrained unions in C. Actually, using a collection of g.Bunch objects containing different ivars is equivalent to programming in assembly language as far as type inference is concerned! All bets are off. The programmer must rely on flow analysis to determine whether references to any particular ivar of a g.Bunch is going to throw an AttributeError. This is an utterly intolerable situation for complex code. I don't recall how this present code evolved as it has. It may actually have started as C unions, although that seems a bit unlikely. Perhaps the real reason for this mess is that handling Leo's settings is inherently a bit messy. There are lots of different *kinds* of settings, and different settings take different kinds of values. Without quite a bit of discipline, the code can accumulate layer upon layer of seemingly innocent hacks. The cumulative effect of these hacks is to undermine all confidence in our ability to understand the actual types of objects. Key-related settings are particularly messy, especially settings in @mode nodes. The first step in getting control of the situation was to replace all g.Bunch objects in leoConfig.py and leoKeys.py with two new classes: GeneralSetting and ShortcutInfo. Leo creates ShortcutInfo objects when parsing key-related settings. Leo creates GeneralSetting objects for all other kinds of settings. This scheme is *far* from a perfect solution. In fact, at an important level, replacing g.Bunch objects with GeneralSetting or ShortcutInfo objects changes almost nothing. There is still considerable uncertainty about the effective types of objects. You could even say that these two new classes do nothing much more than make traces more understandable. That's true. But it's a (tiny) step in the right direction. Another reason for the confusion about types is that the fundamental settings dictionaries don't really care about the types of data they contain. Before today, these dictionaries returned lists of g.Bunch objects. This made the code easy to write, but hard to use. I suppose the typical solution would be to define a hierarchy of settings types, with a common API for all subclasses. The idea would be to have the values of the dictionaries be lists of objects all of which are subclasses of the common base class. In practice, the new code already goes about as far as it can in this direction. Indeed, parserBaseClass.set now creates a GeneralSetting object. The only other possible "improvement" would be to make the ShortcutInfo class to be subclasses of GeneralSetting class. I'm not sure this would really help, but I'm considering it. That's all for now. I'll be wrestling with code today. Perhaps some new insights will arise as I work... 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.
