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

[Terry Reedy]

On 6/12/2014 7:35 AM, Saimadhav Heblikar wrote:
> On 12 June 2014 02:50, Terry Reedy <tjreedy at udel.edu> wrote:
>>
>> ConfigHandler.IdleConf.GetCurrentKeySet adjusts definitions on 'Darwin' by changing 'Alt' to 'Option'. On Windows and Linux, instead of replacing, uppercased key definitions could be added, as appropriate.

> I tried that in http://bugs.python.org/issue12387#msg220338. Let me
> know if that is OK. IIUC, next step would be to revert the changes
> made in Windows key set
> (http://hg.python.org/cpython/rev/25fd9aeeff91/).

We should make the 'officially approved' versions be the ones produced 
by the basic mode of the key dialog: Control/Alt/Meta-Key-alpha and 
Control/Alt/Meta-Shift-Key-Alpha. (Or we should change what basic mode 
produces.) Not needing the alternate binding versions will eliminate the 
need to use advanced mode to produce alternate binding versions.

There should be a new patch removing *all* the extraneous definitions, 
not just the new ones. Write a program to remove 
Control/Alt/Meta-Key-Alpha and ()-Shift-Key-alpha. (You could do the few 
latter forms by hand if you prefer).

> AFA tests are concerned to validate the key defs in config-keys.def, I
> have started writing something as below:
> Tokenize the key sequence by splitting on '-'(as in Control-Key-r).
> and do the following:
>
> 1. ascertain the tokens follow correct order
> I will try various combinations in the existing key def and make a
> note of those orderings, which raise an error. Then ensure those
> orderings should fail during testing
>
> 2. In alphabet keybindings(Prefix-Key-x),(x is any alphabet) is it
> necessary that x be the lower case? If yes, this is something which
> can be tested.

I think accepting the 'wrong' versions (such as the ones we remove from 
the Windows defs) either as an alternative or as supplement to the wrong 
versions, depends on the place encountered. We need to list all and 
decide for each.

0. Key dialog, basic mode - only produces official versions, I believe.
1. Key dialog, advanced mode - either reject or convert to official 
version, if not present, as part of added validation.  A message box 
could give the user a choice.
2. Runtime: I would be inclined to accept without comment (message box). 
However, I do not know how 3rd party extensions get 'installed'.
3. test_configuration, on default files, should fail on wrong versions. 
The assert should have a message argument that would be useful to users 
that mis-edit the default files.
4. test_configuration: we could consider looking for and testing user 
configuration files.

Either configHandler or keybindingDialog should gain a key-binding test 
function that can be imported and used in other modules.

> 3. Test simple scenarios like incomplete keybinding like missing '>' at the end.
>
> The above tests will go into test_keys in
> test_configuration.py(http://bugs.python.org/issue21696).
>
> We can also run the above 3 tests on extension keybindings in
> config-extensions.def.

Terry