[Idle-dev] idlefork - keybinding config / idle extensions
Stephen M. Gava
elguavas@users.sourceforge.net
Mon, 3 Dec 2001 22:24:46 +1100
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 "