Author terry.reedy
Recipients serhiy.storchaka, terry.reedy
Date 2016-06-01.09:15:30
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
Seems reasonable.

3 or more years ago, there was an issue about needing to define pairs like Control-Key-c and Control-Key-C in order to have crtl + c/C-key work the same regardless of the caps lock setting.  I also remember that the effect of Caps lock was system dependent.  But I forget the details.  We should find the issue and document the system dependent rules, perhaps in, perhaps in config-keys.def.

Adding a new default key set will likely not be as simple as we wish.  The problem is the same one we had when adding a new default color theme last fall.  If one selects the new definition, older releases will try and fail to load what is not there.  Keys have a different backup logic than themes, including the 'last resort fallback' in IdleConf.GetCoreKeys.  With thems the result was errors and or an exit.  Have you, or can you check what happens if you select 'Modern Unix' and run an existing release.

If necessary, we can use the same workaround we did with theme, which is described in the docstring for IdleConf.CurrentTheme.  Part the theme patch was making sure that all of the rest of IDLE accessed the current theme through the rewritten CurrentTheme instead of through GetOption('main', 'Theme', ...).

I would like to add some unittests, but a manual test protocol is needed at least to test an existing release.  Tests should be run on each of the three systems, and for each backported version.  When we have a tested patch ready, we could ask New to test on Mac, or do you have access to one now?
Date User Action Args
2016-06-01 09:15:30terry.reedysetrecipients: + terry.reedy, serhiy.storchaka
2016-06-01 09:15:30terry.reedysetmessageid: <>
2016-06-01 09:15:30terry.reedylinkissue27173 messages
2016-06-01 09:15:30terry.reedycreate