GNU Emacs style default key bindings?

Robert> However, I am shocked to find that Xemacs does not use the Robert> same default key bindings as Emacs (which have been burned Robert> into my fingers by years of use.) I've looked in the Robert> Xemacs FAQ's but could not find anything appropriate. Hmm. I don't use the FSF's version much any more but never really noticed a difference in keybindings. It would help if we knew precisely which bindings are bothering you. We have historically tried not to introduce gratuitous differences.[1] People have do different ideas about what's good. XEmacs has built-in capabilities and standard libraries that the FSF's implementation does not, and people want keybindings for those. Given limited space in the keymap, that means other things have to get moved around. There also some things that are just implemented differently (backspace / delete autorecognition is one that comes to mind) so are likely to behave differently. It's possible that you don't mean the keybindings, but instead the behavior of the commands themselves. Some side effects of standard commands do differ by default. The most obtrusive one has to do with regions. In the FSF version, many motion commands (especially search commands) activate the region, while for XEmacs this is generally not true. To alter this behavior, set the variable zmacs-regions. From the manual: `zmacs-regions' is a built-in boolean variable. Value: t Documentation: *Whether LISPM-style active regions should be used. This means that commands which operate on the region (the area between the point and the mark) will only work while the region is in the ``active'' state, which is indicated by highlighting. Executing most commands causes the region to not be in the active state, so (for example) C-w will only work immediately after activating the region. More specifically: - Commands which operate on the region only work if the region is active. - Only a very small set of commands cause the region to become active: Those commands whose semantics are to mark an area, like mark-defun. - The region is deactivated after each command that is executed, except: - "Motion" commands do not change whether the region is active or not. set-mark-command (C-SPC) pushes a mark and activates the region. Moving the cursor with normal motion commands (C-n, C-p, etc) will cause the region between point and the recently-pushed mark to be highlighted. It will remain highlighted until some non-motion command is executed. exchange-point-and-mark (C-x C-x) activates the region. So if you mark a region and execute a command that operates on it, you can reactivate the same region with C-x C-x (or perhaps C-x C-x C-x C-x) to operate on it again. Generally, commands which push marks as a means of navigation (like beginning-of-buffer and end-of-buffer (M-< and M->)) do not activate the region. But commands which push marks as a means of marking an area of text (like mark-defun (M-C-h), mark-word (M-＠) or mark-whole-buffer (C-x h)) do activate the region. The way the command loop actually works with regard to deactivating the region is as follows: - If the variable `zmacs-region-stays' has been set to t during the command just executed, the region is left alone (this is how the motion commands make the region stay around; see the `_' flag in the `interactive' specification). `zmacs-region-stays' is reset to nil before each command is executed. - If the function `zmacs-activate-region' has been called during the command just executed, the region is left alone. Very few functions should actually call this function. - Otherwise, if the region is active, the region is deactivated and the `zmacs-deactivate-region-hook' is called. Jan Vroonhof is working on implementing "Customize themes" to provide a general solution to this kind of problem, but at the moment for keymaps this just a proposal for 21.2 or more likely 21.3. "Just like the FSF's keymaps" is actually a rather uncommon request (people often want some particular subset of bindings from the FSF, but like XEmacs's keymap in other aspects). So there isn't a compatibility mode. It is quite possible that somebody does have a suite of bindings they could copy from ~/.emacs and pass to you, but they'd need to know what you need. Footnotes: [1] This may change in the future since there is a faction that wants more Windows compatibility such as menu accelerators and keyboard access to menus, and similarly advocates Windows-compatible keybindings---making these the defaults will be strenously resisted until "themes" are implemented, though. -- University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Institute of Policy and Planning Sciences Tel/fax: +81 (298) 53-5091 _________________ _________________ _________________ _________________ What are those straight lines for? "XEmacs rules."