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

[Saimadhav Heblikar]

On 12 June 2014 02:50, Terry Reedy <tjreedy at udel.edu> wrote:

>
>
>  2) Issue11437: Its hard to explain this issue in short.
>>>>
>>>
> In long: 12387 is about the config-keys.def that we deliver. 21696 is
> about testing all the default confix-xyz.defs we deliver. However, that is
> not enough because users can edit these files (but should not) and more so
> because they can easily make bad user .defs either with the key dialog or
> by direct editing. (Indeed, the Basic method prevents making the alpha
> pairs, discussed above, needed for Windows. Fixing this is a separate
> issue.) 11437 is about what Idle should do other than closing when it
> encounters a bad key binding.
>
> Serwy's patch validate keys when read. There are two sub-issues.
>
> The patch validates by binding to a temporary Tk() instance and catching
> the TclException. An alternative is to to developed a parser sufficient to
> own needs that also gives more specific errors and which can be used with
> the key dialog. I agree that we should attempt this.
>
>
I detailed how I plan to accomplish in an earlier message.(Please see the
tests part in
https://mail.python.org/pipermail/idle-dev/2014-June/003435.html).
Mention any validity test that I have missed.
The tests will go into test_configuration.py. Could we can run that
unittest method, before IDLE starts? If the test fails, provide appropriate
error message, as in R. Serwy's patch?



> To work around the fact that Idle "calls GetCurrentKeySet for each loaded
> extension" and to avoid repeated error messages, the patch tries to save
> errors that have been reported. The comments indicate that this hack has
> glitches. I would strongly prefer avoiding the repeated calls.



The repeated calls happen in line 1055
load_standard_extensions method where it repeatedly calls load_extension
method->GetExtensionKeys->GetCurrentKeySet.

One obvious way, is to cache the result(activeKeys) in EditorWindow at
startup. Add an optional arg "activeKeys" in the above method chain. I am
linking to the diff file here as i could not find an open issue on tracker.

https://gist.github.com/sahutd/474031c15ee0154ef4bc#file-avoid-repeated-calls-diff

Command used to profile:
./python -m cProfile -s ncalls Lib/idlelib/idle.py >profile.txt && cat
profile.txt | grep "configHandler.py" > file.txt

I have also added  before and after profile. Notice that the TOTAL number
of calls to methods in configHandler.py ~== the number of calls made to
just Get earlier.

https://gist.github.com/sahutd/474031c15ee0154ef4bc#file-profile-before-txt
https://gist.github.com/sahutd/474031c15ee0154ef4bc#file-profile-after-txt



>
>
> >>> Please read the issue
>
>>  at http://bugs.python.org/issue11437
>>>> Workaround:
>>>> This is easy to solve, if we use the solution from issue12387.
>>>>
>>>
> Completing windows binding pairs in config-keys.def has little to do with
> this issue.
>
>
I was referring to binding "redundant" and un-used respective shift events
to <<do-nothing>>.
But since I did http://bugs.python.org/issue12387#msg220338 based on your
comments, my workaround is not applicable.



>
>  With the parser method, both "simple" and "advanced" dialogs
>>>>
>>> >>> will be parsed, and we will have a 1-to-1 mapping.
>
> I am not exactly sure what you mean by 1-to-1 mapping in this context.
> Between what and what?
>
>
For eg, Control Key press + alphabet should not depend on on status of
CAPS.
In retrospect, I should have put it as " one to many mapping."
i.e.
Control Key press + alphabet -> {Control-Key-x and Control-Key-X}
But this too, should not apply now.



>
>  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.
>>>>
>>>
> I don't see how we can do anything between when Idle leaves the factory
> and when the user starts Idle -- unless the user happens to run the tests.
>
>
Perhaps along the lines of R. Serwy's patch. I described how I intend to do
it earlier in this mail.

Regards
Saimadhav Heblikar
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/idle-dev/attachments/20140612/6054749a/attachment.html>