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

[Stephen M. Gava]

Greetings IDLErs.

I've been doing some work on the new gui-workable configuration system in 
idlefork and I've run up against a few issues with user configurable 
keybindings, particularly relating to the idle 'extensions' system, so I'm 
outlining my ideas on how to move forward with this here in case anyone has 
some objections or brilliant ideas on the subject that haven't occurred to me 
(quite likely, brilliant ideas not occuring to me that is :).  I'll start out 
with a brief description of some of the general changes I've needed to make, 
and then move on to a description of how I currently forsee handling the 
'extensions' problem for keybindings.

The 'keybindings situation' in idle is another of those where earlier design 
decisions were (quite rightfully) made without undue regard for the idea that 
one day in a distant and unforeseen future idle might be easily configurable 
through a gui (without needing to edit config files, and resolve conflicts 
between config files, by hand) , but there are also particular peculiarites 
(to my mind at least) about some of the assumptions made in the existing 
keybinding handling that hopefully will be cleaned up now that the config 
system is being completely rewritten. 

One of these peculiarities has been the assumption that it was a useful 
concept to have keybindings be tied to 'platforms' rather than user 
preference.  So idle had a system where it would automatically pick (for you) 
one set of keybindings when running under windows, and another when running 
on unix, for instance. To my mind this is particularly strange for a number 
of reasons. For instance the default 'windows' keybindings were largely 
CUA-ish, which of course is fine for windows, but then, is equally fine for 
for emulating unix editors like (the excellent) Nedit, or for most mac or 
os/2 editors; while the existing 'unix' keybindings are fairly emacs-ish, and 
therefore unlike those of some other popular unix editors, and then also many 
emacs fans use emacs on windows as well as unix, etc....  Isn't it a _user_ 
preference for editor keybinding styles that we're talking about here rather 
than one dictated by or dependant on computing platform or operating system?

In any case this will become a moot point under the new config system, where 
the user will have a choice between available pre-configured keybinding sets 
(including of course a 'windows' or 'CUA-like' set and an 'emacs-like' set) 
to suit themselves, irrespective of platform, as well as being able to easily 
define and reconfigure their own sets of keybindings (more than one, if they 
like). However,  this refocussing of emphasis in keystrokes from 
platform-specific to user-specific causes particular complications with 
idle's existing implementation of 'extensions'.

In the existing model of idle 'extensions' each extension can define it's own 
set of keybindings for each or any platform that the traditional idle 
keystroke handling system deigned to recognise, that is an extension can 
define it's own keys to be bound under windows or unix, for example, just as 
with the general idle keystrokes. This was all well and good in being 
consistent with the exisitng model, because it enabled the extension to 
define default keys for each platform that did not clash (hopefully!) with 
the default general idle keys, or the default keys of any other enabled 
extension, for that paltform. This worked of course on the basis that all 
those other platform specific keys were already known, or that if a 
'knowledgeable user' edited the platform key definitions by hand to customise 
them, then they'd also be knowledgable enough to make sure they sorted out 
any conflicts with other general or extension-specified platform keybindings, 
by editing keydefs.py and the source file for every extension that might have 
defined a clashing platform keybinding...

This obviously complicates things greatly beyond the notion of simply having 
one central set of keybindings that can be relatively easily user/gui 
configured. But, since the idea of extensions is one that isn't going to go 
away in idle (nor should it, I'm reliably informed that some organisiations 
use custom built in-house idle extensions)  I think the best (in fact only 
clear) course forward is to firstly lessen some of the complexity of the 
exisitng extension-keystroke situation, and then to implement user keystroke 
configuration (with programmatic keystroke 'conflict resolution') for 
extensions also. (This latter may [but may not] require some small changes to 
the extensions 'api'?)

Of the extensions that are currently (and mostly have been for quite some 
time) part of the default idle installation I think there is at least one 
(there may be others) clear candidate for removal of 'extension' status and 
treating instead as part of idle proper, that candidate is, 
SearchBindings.py. This module provides a lot of functionality that is surely 
fundamental to any notion of an ide or code editor (that is, all the expected 
advanced search and replace functions) and  it defines an awful lot of 
important (again, pretty much fundamental) keybindings for search and replace 
and navigation functions.  I think SearchBindings.py should be declared a 
basic part of core idle and its keybindings moved into the general idle 
keybinding set so that they can be managed and configured there, where one 
would rightfully expect to find them.

By making that one change in the status of one module alone I think (on the 
issue of keybindings) that all the keybindings for fundamental core idle 
actions will be in their correct place. Then the case of keybinding 
configuration for the remaining extensions (and any new ones) can be more 
sensibly handled with programmatic (configuration gui) resolution of of 
clashes back to the 'core' keybindings or the keybindings of other active 
extensions.

That's about it. If there aren't any objections or inspirations on the 
subject then I shall go bumbling ahead according to the steps I've suggested 
above.

Congratulations if you made it to here and you're still awake,
(if you made it to here and you're asleep, go to bed immediately!),
Stephen.
-- 
Stephen M. Gava  <elguavas@users.sourceforge.net>
IDLEfork ( http://idlefork.sourceforge.net )  " just like IDLE, only crunchy "