[Idle-dev] Re: idlefork - keybinding config / idle extensions

[Stephen M. Gava]

I quote some points from a private email to me here, with Hernan's permission:
Hernan Martinez Foffani wrote:
> agree with you that the "OS type" choice for keybindings
> is a bit "hard". I like your approach of giving a standard set
> of prepackage bindings like "MS Windows", "Emacs", or whatever
> and letting the user create and modify new and existing schemes.
>
> I agree that there's a problem there. But I've got lost on your
> propositions, besides the one regarding the "find text" extension.
>
> If you are going to provide a keybinding configuration for
> the extensions, I don't see the need to change the status of
> the standard ones. Or are you planning to do it in different
> releases?

I think my original message to idle-dev on this probably suffered from the 
problem of these being issues that I've been turning over a lot in my mind, 
and that in being too close to the matter, what I worte came out in 
somewhat of an ill-explained manner.

Really the points are these: 

1. Moving from 'platform' oriented keybindings to user oriented ones.  I must 
admit that this one is slightly more than just a 'proposal', since I've 
already implemented things this way...   8^) , so, more properly consder this 
a 'news item'.

2. It's 'one in all in'.  It really isn't possible to satisfactorily 
implement user configurable key bindings for idle 'core', while 
leaving extension's key bindings hard-coded in their modules. This problem 
with extensions needs to be addressed in some way. Now. (see point 4 also)

3. SearchBindings.py is a special case since I'm firmly convinced that the 
functions it implements are core to idle, not peripheral or optional, and so 
I think it's keybindings sould be part of the idle core keybindings and 
therefore handled by the idle core keybinding configuration mechanism, not by 
whatever additional mechanism is put in place to handle keybindings for 
extensions.

4. The practicalities of handling user configuration of extension keybindings 
are these:  
a)  extension keybindings will need to be defined in one of idle's new 
configuration files (probably most properly in the relevant sections of 
config-extensions.def), _not_ inside the extension source modules.
b)  whatever mechanism is implemented for allowing user configuration of 
extension keybindings (at the moment I have several different possible 
approaches in mind) it must allow this configuration to participate in the 
general abilty to handle and resolve potential clashes between keybindings 
that will be a part of the core keybinding config handling.  (ie. obviously 
you can't use the same keybindings more than once, in any given keybinding 
set, for core keybindings, _or_ extensions).    

> As an IDLE user, for me is more useful to have
> a way to specify keybindings in an non-OS manner but rather
> in a scheme and user configurable way (that include standard
> extensions and the ones written by me!), than to do it GUI.

For sure the 'sensible implementation' is much more important than the gui 
(and of course can and should exist happily without it ), but the goal of  
the new config implementation is to also have easy gui configuration, to make 
idle a more comfortable environment for one and all, including those who 
would never edit config files by hand. 

Regards,
Stephen.
-- 
Stephen M. Gava  <elguavas@users.sourceforge.net>
IDLEfork ( http://idlefork.sourceforge.net )  " just like IDLE, only crunchy "