Re: XEmacs 21 /vs./ my keyboard: I want my DEL back
Martin Buchholz wrote:
Karl> Spare me the crap -- I'm not lying to anything or
anybody. I'm using
Karl> the advertised features of the supplied program, precisely in the
Karl> manner in which they are intended to be used -- I'm using the
Karl> configurability of xterm to make my life easier, by changing its
Karl> standardized behavior to something more personally palatable. Gee,
Karl> howzabout that. If I then have to fart around with *XEmacs'* new
Karl> misconceptions of standardized behavior to get corrected personalized
Karl> behavior, am I "lying" to XEmacs?
Karl> Of course not. What semantic nonsense.
Of course not NOT. The sequences sent by keys on the keyboard are
supposed to match the entries in the terminfo entry. If they don't,
the application can't be expected to recognize them. If you change
one without the other, then you should not be disappointed if your
applications cannot recognize your function keys.
Note that this doesn't necessarily apply to the VERASE character,
though. If the tty is in canonical (ICANON) mode, the application will
never get to see the keypress; the tty driver will silently delete the
previous character from the input buffer.
Now, XEmacs uses raw mode, but there is a valid argument for
consistency with the tty driver. If the tty driver considers \177 to
be `delete backwards', then (IMHO) so should XEmacs.
In Karl's previous post, he wrote:
[1007] [22:30:27] beaver:~> stty -a
speed 38400 baud; rows 67; columns 80; line = 0;
intr = ^C; quit = ^\; erase = ^?; kill = ^G; eof = ^D; eol = <undef>;
^^
I hit the key that generates \177 in an xterm, and XEmacs 21 calls it
a "BS". This is wrong.
From the above output, I would assume that if you type:
$ cat
hello <- <- <- <- <-
(where `<-' represents `the key that generates \177 in an xterm'), it
will delete backwards. This behaviour is what is generally termed
`backspace'.
The intent of the current behaviour is basically to try to get the
upper-right-key-with-a-left-arrow-on-it to generate the `backspace'
keysym regardless of whether you are running under X or on a terminal
emulator.
There is no guaranteed way of knowing whether this key generates \010,
\177, or something else. The current behaviour (i.e. whichever code
corresponds to the VERASE character) is simply the best guess that
anyone could come up with.
Hardcoding \010 -> backspace is bad, as it interferes with C-h for
help. Many people, myself included, have something like
XTerm*VT100.Translations: #override \
<Key>BackSpace: string(0x7F)\n
specifically so that the <- key can be distinguished from C-h.
Ideally, XEmacs will then map \177 back to backspace for consistency
with X.
Hardcoding \177 -> delete (the old behaviour) is also bad, as many of
the lisp/term/*.el files map e.g. \e[3~ -> delete. This made it
impossible to distinguish between the two deletion keys on a tty.
The new behaviour:
a) makes it possible to configure which code generates the backspace
keysym (via tty-erase-char), and
b) does the best job possible (IMHO) of choosing a suitable default.
--
Glynn Clements <glynn(a)sensei.co.uk>