Glynn Clements <glynn(a)sensei.co.uk> writes:
> XEmacs treats the code which corresponds to the VERASE character as
> Backspace (i.e. it is consistent with the kernel's tty driver). If
> your Backspace key generates \010, then you need to use
> stty erase ^V^H
> to tell the tty driver about it.
No.
[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.
The fundamental problem is that, within a terminal, the set of 3
distinct concepts "Delete", "Backspace", and "`C-h'" do not all exist,
the 2nd & 3rd being the same thing. XEmacs 21 has mis-commandeered
the first, which arrives as \177, misinterpreting it as "BS", which
doesn't even exist in a terminal.
This breaks many standard and common keymaps, Gnus' keymaps just being
particularly good examples of a large, complex system's keymaps which
have lots of references to multi-key sequences including <delete> but
which have no knowledge of this peculiar thing called "BS". (Just to
expand on the example, Gnus' *Group* buffer believes in "G delete" and
"T delete", neither of which works in an xterm due to this problem.)
20.4 shares none of this braindamage, which understands "delete" in
all contexts. 20.4 tells me that "delete runs the command
backward-or-forward-delete-char" and "B delete runs the command
gnus-summary-delete-article" when run both under X directly and within
an xterm.