[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