[Idle-dev] KeyConfig, KeyBinding and other related issues.

Saimadhav Heblikar saimadhavheblikar at gmail.com
Fri Jun 13 17:44:40 CEST 2014


I would like the keyseq validator to be reviewed.

The diff file: https://gist.github.com/sahutd/0a471db8138383fd73b2#file-test-keyseq-diff
A sample test runner file:

In its current form, it supports/has
    modifiers = ['Shift', 'Control', 'Alt', 'Meta']
    alpha_uppercase = ['A']
    alpha_lowercase = ['a']
    direction = ['Up',]
    direction_key = ['Key-Up']

It supports validating combinations upto 4 in length.

Please test for the above set only. (It will extended easily to fully
represent the respective complete sets. The reason it cant be done
*now* is the due to how RE optionals are coded differently in my
patch. See CLEANUP below). I will also add remaining keys like
Backspace, Slash etc tomorrow.

# Cleanup:
If we decide to go ahead with RE validating keys as in the above patch,

0. I made the mistake of not coding RE optionals -> ((pat)|(pat)) same
for all sets. The result is that, extending the current key set is not
possible without making all RE optional patterns similar.(Read the
starting lines of is_valid_keyseq method).

1. There is a lot of places where refactoring can be done and
appropriate comment added.

2. I left the asserts as-is. They can be used in testing the validator
method itself.

3. The above patch still needs support for Backspace, slash etc to be
added. I decided to add, once I am sure we will use it.

4. I would like to know how it will affect Mac? What are system
specific differences? Please run the test-runner script on it and do
let me know.

My friend told that this thing can be done by "defining a grammar and
automata." I did read up about it, but found it hard to grasp
everything. Can you say whether it would be easier to solve it that
way than RE?


More information about the IDLE-dev mailing list