On Feb 6, 6:58 am, "Edward K. Ream" <[email protected]> wrote:
> it is truly impossible to understand the key code without knowing whether an > object is a string representing a user setting or the canonicalized version > used in Leo's core, that is, a KeyStroke object. There is another set of strings floating around the key-handling code, namely Leo's emacs-like command names. I am considering defining a new class, say k.CommandName, to wrap such names. If I do that, I'll base the k.KeyStroke and k.CommandName classes on a common g.TypedString class. I am about to convert many of Leo's key-handling dictionaries to g.TypedDict objects. Using TypedDicts will make it impossible to make invalid assignments to Leo's crucial key dictionaries, especially if I create the CommandName class. In effect, g.TypedDict objects will enforce the constraints given in the comments in << about key dicts >> in leoKeys.py. This machinery will allow further type-related assertions. Details omitted, but they will be quite useful, both as sanity checks and as documentation. The TypedDict class enforces its own type constrains automatically, so the crucial type checks will not unduly clutter the code. 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.
