>>>> "Karl" == Karl Kleinpaste
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
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.