Karl> But the problem with remapping \177 as keysym "BS" is that it means Karl> one's keyboard is not bound the same way under X /vs./ inside an xterm. Karl> Right now, I've got two XEmacsen running Gnus: One locally, under X, Karl> on my main home system for mail which I handle here (charcoal.com), Karl> and one remotely, inside a local xterm, at JPRC for most things. Karl> Under X, I hit Delete and I get DEL, I hit Backspace and I get BS, I Karl> hit `C-h' and I get `C-h'. These bindings seem to be shifted Karl> circularly inside an xterm, so that I hit Delete and I get BS, and I Karl> hit Backspace and I get `C-h'. This is to say that I can't even Karl> expect to get the same result from hitting the exact same keys within Karl> an xterm as I get under X. Karl> This is extremely peculiar, and a fabulous loss of coherency to me. Some vendors ship an xterm that maps the key in the upper right part of the main keyboard to the ASCII character `^H', others ship it so that it sends `^?'. XEmacs can't tell the difference. Essentially, when XEmacs gets a `^H' or a `^?' in tty mode, it has NO idea what actual key the user pressed on the keyboard. The user might be using a terminal emulator on a Mac, or a real hardware vt100, or ... So XEmacs relies on the tty settings, which it *can* examine. Karl> It's not a matter of being a crusty holdover to DEC; it's a matter of Karl> a single keyboard attached to 2 instances of a single program not Karl> providing identical keyboard interfaces. In order to get the same Karl> keyboard interface, every keymap in every XEmacs mode will have to Karl> duplicate every entry containing <delete> so that it also binds the The legacy keybindings are a problem, for sure. Some lisp packages will have to be made aware of the issues involved here for optimal results. Much of this has already been done. Karl> <backspace> case. Until that happens, lots of other folks who, as Karl> myself, split a lot of time between "under X" and "in an xterm" will Karl> find exactly the same problem, and if 21 were to go out the door the Karl> way it is right now, most of those other folks wouldn't be very Karl> understanding of the soft underbelly of the Keymap Purity Hit Squad; Karl> they'll just complain about why their Delete has stopped being a Karl> <delete>...but only in an xterm. Philosophy is great, but it doesn't Karl> solve the problem of lost keymap capabilities. Karl> 20.4 had no problem with this. In 20.4, at least the limit of Karl> X/terminal keymap difficulty was that hitting the Backspace key simply Karl> unavoidably duplicated the existing binding on `C-h'. 20.4 didn't Karl> willfully *move* one binding to another key, which is what 21 has done. What we certainly do want to achieve is that the user by default deletes backward (never enters help!) when hitting the key labelled backspace, and deletes forward when hitting the key labelled delete. The current implementation may not be perfect, but we have to try to achieve this goal. Perhaps you would like to help? Be warned that it's really hard to come up with a solution that makes everyone happy. Martin