This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author terry.reedy
Recipients Saimadhav.Heblikar, terry.reedy
Date 2014-05-19.01:57:11
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1400464633.29.0.222732993428.issue21519@psf.upfronthosting.co.za>
In-reply-to
Content
> Now the <Control-Key-C> binding will be assigned to two actions.

I do not see this. I only see <Control-Key-c> duplicated, which is bad enough to be patched. What did you leave out ;-).

Also see #12387, which we need to finish, and Ned's link to  http://wiki.tcl.tk/28331 

A patch for KeysOK should include test_bindings.py with class KeysOK_Test. As with the test of name_ok in test_configname.py (sp?), the method should be embedded in a dummy class and use a dummy message box.

The problem with the method goes deeper. It is not called if the 'advanced' (hand entry, therefore primitive) pane is used. As near as I can tell (and if I am wrong, please tell me), multiple bindings, which are required to ignore lower-upper case issues, can only be entered with this 'advanced' method. Hence, most new entries are not checked at all. The basic pane, which is advanced in that one can only enter possibly valid combination, should be modified to allow multiple entries. (The two panes should be called 'Easy' and 'Error-prone ;-)

As it is, 'keys' is a misnomer[note], "keys.strip()" is a no-op in that 'keys' is auto-generated, and "keySequence = keys.split()" is the same as "keySequence = [keys]"[note]. Many of the tests only test mistakes that can happen with hand-entry, which is not tested. I believe that the duplicate check is the only one needed (except possible for the modifier check, which I have not looked at enough to tell).

[note] If the easy pane were modified to define multiple keys, and all were passed at once, then the two noted lines would become valid, but then each key, would have to be tested individually against the flat list.

This suggests to me that the flattening should be done just once and that KeysOK should become KeyOK, or rather key_ok. It might even be replaced by "newkey in flat_list" or something nearly that simple.
History
Date User Action Args
2014-05-19 01:57:13terry.reedysetrecipients: + terry.reedy, Saimadhav.Heblikar
2014-05-19 01:57:13terry.reedysetmessageid: <1400464633.29.0.222732993428.issue21519@psf.upfronthosting.co.za>
2014-05-19 01:57:13terry.reedylinkissue21519 messages
2014-05-19 01:57:11terry.reedycreate