I am digging up a previous topic, the
single keybinding configuration for the workbench:
Having a single keybinding configuration
for the entire workbench is not sufficient. Currently, the user can
choose between "default" and "emacs" modes. These
modes only make sense for source editors, and do not apply to other types
of editors, such as HTML editors.
An HTML editor might define new configurations
called "frontpage" and "dreamweaver". Now, if
the user wishes to activate both "dreamweaver" and "emacs",
which makes sense because these are completely orthogonal functions, he
cannot.
Perhaps the solution is to add a new
concept called a "domain", or some other vague grouping terminology
<g>. And, since the current UI for editing keybindings does
not scale very well, it might make sense for plug-ins to start re-using
the keybinding page under their own preferences subtree, instead of just
adding and adding more and more entries into a global one. This way,
domains wouldn't be exposed to the user, but would be implied by the place
where they found the keybinding page, for example, "Webtooling->HTML
Keybindings".
As was discussed last time I brought
this up, a workaround is to have the HTML editor use scopes as the way
to implement its configurations. But this means that the HTML editor
cannot use scopes for what they were intended, so it could not define a
"JSP" scope which inherited from the "HTML" scope.