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

Terry Reedy tjreedy at udel.edu
Fri Jun 13 02:55:33 CEST 2014


On 6/12/2014 6:20 PM, Tal Einat wrote:
> On Thu, Jun 12, 2014 at 10:10 PM, Terry Reedy <tjreedy at udel.edu> wrote:
>> We should make the 'officially approved' versions be the ones produced by
>> the basic mode of the key dialog: Control/Alt/Meta-Key-alpha and
>> Control/Alt/Meta-Shift-Key-Alpha. (Or we should change what basic mode
>> produces.) Not needing the alternate binding versions will eliminate the
>> need to use advanced mode to produce alternate binding versions.
>
> What about Ctrl-Alt-Key-Alpha or even Ctrl-Alt-Shift-Key-Alpha? Even
> if there are now such bindings right now, they should be possible to
> enter via the simple key binding dialog, and they should be considered
> valid.

Each of the three can be independently selected. The RE for what basic 
produces is something like '<(Control-)?(Alt-)?(Shift-)?Key-(any from 
list)>"

>> There should be a new patch removing *all* the extraneous definitions, not
>> just the new ones. Write a program to remove Control/Alt/Meta-Key-Alpha and
>> ()-Shift-Key-alpha. (You could do the few latter forms by hand if you
>> prefer).
>
> Indeed. We'll need to manually review this by hand, but it might be
> better to do most of this automatically to reduce the risk of human
> error. Possibly a few good search/replace in an editor could do the
> trick.

An RE search-delete with ", <(Control-|Alt-|Meta-)Key-[A-Z]>" should do 
it for in the Windows section. I did not see any matches in the Unix 
section but did not look in the Mac/OSX sections. Those should be left 
alone anyway except as Ned thinks they should be changed.

>> 2. Runtime: I would be inclined to accept without comment (message box).
>> However, I do not know how 3rd party extensions get 'installed'.
>
> What do you mean "installed"? I know a lot about the extension
> mechanism and will happily help here.

I think I found much of the current answer in the config-extensions.def 
comments. Someone puts an extension file in idlelib and, adds *by hand*, 
a corresponding entry to idlelib/config-extensions.def. This entry 
defines the system defaults for the extension and constitutes 
'installation' as I meant it. A user on the system customizes added 
extensions just like built-in extensions: hand-edit 
.idlerc/config-extensions.cfg to add a custom entry.

As I understand it, your extensions dialog will take care of the second 
part, editing the user file, but depends on entries already being in the 
default file.

Idle does not seem to have anticipated an ecosystem of 3rd-party 
extensions, and the waste of 1000s of people hand-editing 
config-extensions.def. A feature complementary to editing existing 
entries would be automatic recognition of new extensions and copying of 
an config entry from extension file to the .def file.  Are there any 
some extensions that come with a script to do this?

Proposal: define a format for config entries in .py files, perhaps 
copying one already in use if there are any. Add a directory, such as 
/extensions to contain files that have such entries. The rest should be 
easy enough to work out.

Terry




More information about the IDLE-dev mailing list