Better Support for Windows Style Key Bindings

Owner: ???

Effort: ???

Dependencies: ???

Abstract: This page describes how we could create an XEmacs extension that modifies the global key bindings so that a Windows user would feel at home when using the keyboard in XEmacs. Some of these bindings don't conflict with standard XEmacs keybindings and should be added by default, or at the very least under Windows, and probably under X Windows as well. Other key bindings would need to be implemented in a Windows compatibility extension which can be enabled and disabled on the fly, following the conventions outlined in Standard interface for enabling extensions Ideally, this should be implemented using the keyboard action interface but these wil not be available in the short term, so we will have to resort to some awful kludges, following the model of Michael Kifer's Viper mode.

We really need to make XEmacs provide standard Windows key bindings as much as possible. Currently, for example, there are at least two packages that allow the user to make a selection using the shifted arrow keys, and neither package works all that well, or is maintained. There should be one well-written piece of code that does this, and it should be a standard part of XEmacs. In fact, it should be turned on by default under Windows, and probably under X as well. (As an aside here, one point of contention in how to implement this involves what happens if you select a region using the shifted arrow keys and then hit the regular arrow keys. Does the region remain selected or not? I think there should be a variable that controls which of these two behaviors you want. We can argue over what the default value of this variable should be. The standard Windows behavior here is to keep the region selected, but move the insertion point elsewhere, which is unfortunately impossible to implement in XEmacs.)

Some thought should be given to what to do about the standard Windows control and alt key bindings. Under NTEmacs, there is a variable that controls whether the alt key behaves like the Emacs meta key, or whether it is passed on to the menu as in standard Windows programs. We should surely implement this and put this option on the Options menu. Making Alt-f for example, invoke the File menu, is not all that disruptive in XEmacs, because the user can always type ESC f to get the meta key functionality. Making Control-x, for example, do Cut, is much, much more problematic, of course, but we should consider how to implement this anyway. One possibility would be to move all of the current Emacs control key bindings onto control-shift plus a key, and to make the simple control keys follow the Windows standard as much as possible. This would mean, for example, that we would have the following keybindings:
Control-x ==> Cut
Control-c ==> Copy
Control-v ==> Paste
Control-z ==> Undo
Control-f ==> Find
Control-a ==> Select All
Control-s ==> Save
Control-p ==> Print
Control-y ==> Redo
(this functionality is available in XEmacs with Kyle Jones' redo.el package, but it should be better integrated)
Control-n ==> New
Control-o ==> Open
Control-w ==> Close Window

The changes described in the previous paragraph should be put into an extension named windows-keys.el (see Standard interface for enabling extensions) so that it can be enabled and disabled on the fly using a menu item and can be selected as the default for a particular user in their custom options file. Once this is implemented, the Windows installer should also be modified so that it brings up a dialog box that allows the user to make a selection of which key binding scheme they would prefer as the default, either the XEmacs standard bindings, Vi bindings (which would be Viper mode), Windows-style bindings, Brief, CodeWright, Visual C++, or whatever we manage to implement.

Ben Wing

Conform with <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
Automatically validated by PSGML