Key bindings are used pervasively throughout the OS. Although the InterfaceConsistencyInTextEditing problem may seem like a problem for text editors only, in fact it is a problem for anywhere you might edit text. This includes: the command line, renaming a file, file open boxes, file save as boxes, forms on web pages, etc. Another place where this crops up is in InterfaceConsistencyInSelections.

Although this solution is particularly addressed to text editing keybindings such go-to-next-word, go-to-end-of-line, etc., it could be generalized to keybindings in general. For example, an app could utilize a standard keybindings dialog to present keybindings for the user to edit. This would encourage more apps to make their application-specific bindings available for the user to modify.

Default key bindings in the application could also be derived from editable common key bindings. For example, a key binding for a "rename" action could be useful in many contexts, including the tracker. If the user should decide to change it to F2 for example, then all conforming applications would support it. Note: this would be a default, which could optionally be overriden for a single particular application in that application's key bindings dialog.

side note

At first I had thought to have one dialog where the user could modify all their key bindings for any application. Each compliant application would register their set of key bindings and all would presented in a single interface. However, I have become wary of this.

One pitfall is that one might perceive it as "natural" to keep all these keybindings in one file somewhere. Although the file would start small, it would soon grow. This solution would make it difficult to take a single application and it's keybinding preferences to another platform.

Even if care is made to keep the files separate from one other, applications could also fail to register. If the application is deleted, the application registration could linger on. This poses a problem that is almost but not quite as bad as the windows registry.

Further details

So, for the sake of the presentation, I let applications decide where to keep their own keybindings and also when and how to present the editing of them. As an effort towards consistency I encourage development of a panel that could be presented by any application to change its key bindings. (think open file dialog-type common panel) A key bindings API could be used to encourage the use of the panel and also a consistent save file format. This could also allow for editing key bindings outside the application. Similarly a user interface guidlines document could recommend where this panel would accessed from a typical application's menu tree and also where the resulting file would be saved. (probably in settings.)