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

Tal Einat taleinat at gmail.com
Wed Jun 11 13:21:14 CEST 2014


On Wed, Jun 11, 2014 at 10:31 AM, Terry Reedy <tjreedy at udel.edu> wrote:
>
> On 6/11/2014 2:39 AM, Saimadhav Heblikar wrote:
>>
>> The following are the issues related to shortcuts, keybinding dialog,
>> where the shortcuts are set and config-keys.def where the shortcuts
>> are stored.
>
>
> Great: I have been collecting a list of configuration and especially keybinding issues, with the thought of suggesting this as a coherent group of issues you could work on.
>
> 3068: extension CONFIG dialog, Tal new PATCH, review
> 12274: CONFIG syntax error crash
> 12387: CONFIG KEYboard shortcuts
> 4765: CONFIG custom KEYset deletion, patch fixes (Mark)
> 11437: CONFIG-KEY type causes crash; startup is inefficient. Serwy patch
> 1517993: CONFIG KEY and Macs: (me) Alt to Meta (closed)
> 20580: CONFIG KEY and and Macs
> 694339: dedenting with shift-tab CONFIG KEY
>
> I just added 21519. Related ideas I have not opened issues for:
>
> Save config-KEYs sorted on disk instead of when present in CONFIG DIALOG. Would be much easier to read, just a matter of when sort.
>
> Make CONFIG DIALOG wide enough for all KEY definitions. Also lengthen.
>
> Change some names so they sort better: possible example region-dedent, region-indent instead of dedent-region, indent-region.
>
> Since I have a backlog of new test files to review, + Tal's config-extensions patch (+ a patch by Lita), I was about to suggest that you find something like this (configuration and keybinding) to work on that Tal knows better than me, and could help you with.
>
> It would be great to fix some of these issues that have dragged on for years. If either of you think that some fixes need deeper changes than the typical surface patches, please say so so we can discuss. The better we make the tests, the more confidently we can consider refactorings.
>
> I will look at the specifics below tomorrow. I would like to see Tal's comments either by email or on the tracker.
>
> Terry
>
>
>> 1) Issue12387: Very simple way to reproduce the bug:
>> With/without CAPS, Ctrl + x key, performs Cut action(windows keyset).
>> This is agreeable because both those keybindings are set. The bindings
>> are
>> <Control-Key-x> and <Control-Key-X>
>> But, with/without CAPS, Ctrl + Shift + x key also performs Cut action.
>> The bindings are <Control-Shift-Key-x> and <Control-Shift-Key-X>
>> *Workaround*:
>> Bind the redundant <Control-Shift-Key-x> and <Control-Shifrt-Key-X> to
>> <<do-nothing>>.(already exists).
>>
>> This has to be done for all existing <Ctrl+[A-Z][a-z]> key combinations.
>> For sake of completeness, If the user wants Control + Shift + *x key*,
>> we have to remove both from <<do-nothing>> keybinding and add it to
>> whatever binding that the user wants.
>> This has to be done in the current validity checking method or a new
>> parsing method.
>> I have tested this solution, and am convinced it would work.
>>
>>
>>   2) Issue11437: Its hard to explain this issue in short. Please read the issue
>> at http://bugs.python.org/issue11437
>> Workaround:
>> This is easy to solve, if we use the solution from issue12387. With
>> the parser method, both "simple" and "advanced" dialogs will be
>> parsed, and we will have a 1-to-1 mapping.
>> For the case when someone tries to directly "hand-edit" the config
>> files, with http://bugs.python.org/issue21696 and tests for the parser
>> method in place, we should able to raise an earlier, ideally before
>> IDLE starts. We should also be able to pinpoint where the error
>> occurs.
>>
>>
>> 3) Issue20580: This does not involve coding, but is about providing
>> platform specific default config. This can only be done, once we agree
>> on 1 and 2.
>>
>>
>> 4) Issue21519: Again dependent on 1 and 2. Not too sure, if it is
>> going to be an issue with 1 and 2. If we go ahead with 2, and have a
>> parser method which is testable, we can also validate the "advanced"
>> dialog.
>>
>>
>> For other issues which are caused by typo in config,
>> http://bugs.python.org/issue21696 along with testable parser method
>> should catch them.
>> -----------------
>>
>> I plan to work on these issues in test driven style as suggested by
>> Tal Einat, especially keeping in mind the above issues, their current
>> outcome and the required outcome.
>
>
> PS. For me, feedback after every 'code unit' change* makes coding more fun. I hope my F5 key doesn't wear out '-).
>
> *a minimal change that should increase or restore passing tests.

Saimadhav and I discussed this a bit on IRC yesterday. We started by
discussing caps-lock's effect on key bindings. My conclusions are:

1) We don't want caps-lock to affect IDLE's key bindings.
2) Tk reacts to caps-lock in different ways on different platforms. I
think we should ignore it on all platforms, which means non-trivial
work to get that working right with Tk.
3) Specifically, Tk sometimes changes the case of the letter in the
event it generates depending on whether caps-lock and/or shift are
active. For example, we could get Ctrl-S instead of Ctrl-s if caps
lock is on. How exactly this behaves differs by platform (!). For
example, caps-lock + shift can result on either an upper- or
lower-case letter in the event string, depending on platform. This is
causing the issues with keyboard shortcuts not working with caps-lock
active on some platforms.
4) A possible solution is to treat all keyboard shortcuts which are
bound to a letter in a case-insensitive manner. This would seem to
require parsing Tk event definition strings in order to normalize
them, and binding to both the upper- and lower-case letter Tk events.
5) Parsing the event strings has additional benefits, such as proper
validation of custom events defined in the "advanced" section of the
key binding config. (Validations include checking if there are already
bindings which would catch that event).

This is basically what Terry suggests in his "1)" above, and he says
he's already tested the approach and is convinced it would work. So it
seems we are all agreed on the suggested implementation method :)

Additionally, I suggested that if we go down the route of such a
"deep" change, it could be useful to write at least some tests in
advance for things that do and don't currently work. This will help
make sure that we have a good definition of what currently doesn't
work properly, and that we get it working properly at the end.
However, how good idea this is depends on how difficult it is to write
such tests for the current implementation.

Finally, there is some existing relevant code which parses and
normalizes TK event strings in idlelib/MultiCall.py. It would perhaps
be better to write simpler, more specifically appropriate code, but
that could be a starting point. Terry, perhaps you have something
better that you used in the test you mentioned?

- Tal Einat


More information about the IDLE-dev mailing list