>>>> "Robert" == Robert Yodlowski
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.
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
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
`zmacs-regions' is a built-in boolean variable.
*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.
- 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
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
- 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.
 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."