On 12 June 2014 02:50, Terry Reedy <tjre...@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
_______________________________________________ IDLE-dev mailing list IDLE-dev@python.org https://mail.python.org/mailman/listinfo/idle-dev
