Re: KeyConfig, KeyBinding and other related issues.

Hi,

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:
https://gist.github.com/sahutd/0a471db8138383fd73b2#file-test-keyseq-runner-py

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?

Regards