Chance favors the prepared mind—Louis Pasteur.

When I awoke just now I saw the answer to a question I didn't know my mind 
was working on, namely, how to drastically simplify Leo's key handling 
code, including the key settings.  This is huge.

The work that prepared my mind:

1. The recent ipynb importer code.  It uses nbconvert to translate a string 
(the file's text) into a python data structure, that *contains *text, but 
also contained bools and lists.

2. Recent work on converting Meta to Alt on MacOS.  This reacquainted me 
with the horrors of the code that converts a Qt key event into Leo's 
internal representation.  At present, this representation contains an 
oh-so-fragile string.

3. Yesterday's post on branches.

The Aha:  *Don't use a string to do an object's work!* 

*The plan*1. Just like with nbconvert, Leo's code that handles incoming Qt 
key events will output a python data structure, say LeoKey, *not *a string. 

2. Leo's code that translates user key settings will generate a LeoKey. 
It's not clear what to do about the pane specifiers. It might well be an 
auxiliary field of LeoKeys.

That's all!  But the effects are widespread:

- The code that translates Qt keys to LeoKeys instantly collapses in 

- Ditto for the code that translates user settings to "canonical key 

- Ditto for code that prints/dumps keys and user key settings.

- There is no longer any need to distinguish between canonical and 
non-canonical key *strings.* In particular, the infamous g.KeyStroke class 
will disappear. It's docstring:

    '''A class that announces that its contents has been canonicalized by 
    This allows type-checking assertions in the code.'''


The code that handles Qt key events (the key handler) and the code that 
handles key-related user settings (the key setting handler) will *meet in 
the middle* by producing a common data structure, a LeoKey.  This structure 
will *contain *strings, but will not *be *a string.

For example, the representation of Alt+Ctrl+s will have:

- a mods field: set(['alt', 'ctrl']). This is the big simplification.
- a key field of "s".
- a code field whatever the Qt key code is, for debugging.
- a pane field (set only by the key setting handler) of one of ('all', 
'text', 'outline', 'body', etc.)

No more horrendous "canonicalizing" of key representations!  No more 

I expect to be able to do this work in a day or three.


You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
To post to this group, send email to
Visit this group at
For more options, visit

Reply via email to