Community
Participate
Working Groups
The keybinding preference page(s) does not scale well. The biggest problems are: 1) It shows every context defined 2) commands without default bindings are hard to find 3) conflicts are reported even when they are not actually conflicts. To address this, I think the preference page should be configurable with a specific context, for example, the java source editing context. In this mode, it would display only bindings related to that context, including inherited bindings. It might also include "subclasses" of the current context, at least for the purpose of showing conflicts when creating new assignments. This leaves the problem of determining which commands are related to the selected context hierarchy. I propose that the current mechanism of defining a keybinding for the command be used. But, this should be extended to include no-op keybindings which have no defined sequence, but serve the purpose of associating commands with contexts. For backwards compatibility, a mechanism for finding any command should be included. This might be something like turning off the filter-by-context function.
There is another benefit to associating commands with the contexts in which they actually get handled. This would allow plug-in to declare contexts that are abstract, meaning that that context can never be activated, but concrete sub-contexts could. Commands and keybindings could then be associated with the abstract context. These commands would not pollute the application's keybinding preference page unless a concrete subcontext were declared in some other plug-in.
Moving Dougs bugs
There are currently no plans to work on this feature. PW
Changes requested on bug 193523
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant.
