On Wed, Feb 8, 2012 at 7:19 AM, Edward K. Ream <[email protected]> wrote:
> In fact, [type assertions] make me uneasy. [big snip] > I'll also create two new classes: ModeInfo and ModeController. The first draft of the ModeController class used a g.TypedDict, but this is unnecessary. The code makes it clear that the keys of this dict are whatever aMode.name is, and that clearly doesn't change. This is an example of what I attempting to convey: creating better classes clarifies relationships so much that fancy type checking may not be needed. I am beginning to regard any "long-lived" dict in Leo as a design problem. I plan to enfold many of Leo's key-handling dicts into easier-to-understand classes. Quick: what are the values and keys for k.masterGuiBindingsDict? Or even, what the heck does this dict do? Edward P.S. Creating the ModeInfo class is going to clarify the client code in leoKeys.py considerably. The client code should not know the details of modes; at present, it knows *everything* about modes. P.P.S. It's becoming obvious that the work with leoConfig.py and especially leoKeys.py is an essential precondition to better support of vim bindings and commands. The code is already at the "breaking" point in terms of complexity. It must be dramatically simplified before any additions are possible. P.P.P.S. I am beginning to realize just how much mischief is done by reading settings twice. In particular, the double read greatly complicates the way-too-complex init code for c and c.k objects. EKR -- 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.
