Red Hat Bugzilla – Bug 30872
Meta-Delete on tty causes unhandled suspend
Last modified: 2007-04-18 12:32:02 EDT
From Bugzilla Helper:
User-Agent: Mozilla/4.76 [en] (X11; U; Linux 2.2.12-20ext3 i686; Nav)
When XEmacs is run on a tty with the -nw option, it attempts to disable the
tty's `susp' key (suspend function, normally Control-Z) by setting the key
to the value \377. On Linux, however, this does not disable the key;
instead it means that XEmacs will be blindsided by a suspend command
whenever the user types Meta-Delete (Alt + his backspace key under Linux)
which would normally delete the word to the left of the cursor - a function
very frequently used by some XEmacs users (including myself).
Steps to Reproduce:
1. Start XEmacs with the -nw option so it uses your tty rather than an X
2. (optional) Press ^Z to suspend emacs, then use `fg' to bring it back;
you will observe that XEmacs is well behaved and redraws the screen upon
3. Press what would normally be the delete-word key - the Meta-Delete
combination (probably Alt+Backspace on your Linux keyboard). XEmacs will
be suspended without the chance to return you to your text screen. When
you type `fg' to return, it will not redraw the screen, because it does not
know you have suspended and resumed it.
The cause, as noted above, is that XEmacs is misconfiguing its tty. Once
XEmacs is running, try an `stty -a' on the terminal it is running on (you
might have to use `who am i' in the terminal to discover which device it is
on, then type `stty -a < /dev/the/device'); you will note that it reports
`susp = M-^?' meaning that the meta-delete key will suspend any
applications. If you try `stty susp undef < /dev/the/device' then the
problem should be fixed: meta-delete will start killing words again rather
than suspending emacs. The problem, of course, is that XEmacs should do
this when setting its own terminal settings, and does not. Perhaps it was
designed under an OS where setting TTY keybindings to \377 (meta-delete)
was interpreted as disabling them? I do not know.
Which version of xemacs are you running?
Sorry; version is xemacs-21.1.12-3.
Please update your system with up2date, and try it again: 21.1.14-2.7 is the
newest release for RHL 7.
After upgrading to 21.1.14-2.7 I find that XEmacs has many wonderful new
features, including being able to read MS-DOS files without showing the ^M's at
the end of every line. However, it is still fully susceptible to the bug
OK... I couldn't reproduce it properly here, will look closer into it later.
I cannot reproduce the problem on the Linux console; there, the M-^? tty binding
does not for some reason intercept the Alt+Backspace combination, and it makes
it through to XEmacs and is interpreted correctly. Similarly, I cannot
reproduce the problem under a gnome-terminal (which interprets keystrokes
differently anyway - like ignoring the Meta modifier in favor of the Alt
modifier, and ). The problem only occurs inside of a old-fashioned xterm.
Perhaps recent versions of xterm interpret M-^? as a real key, instead of an
`undefined' flag as the console and gnome-terminal seem to do? If so, who would
we change to make things work consistently in Linux among the different kinds of
OK, I can reproduce it here... I'll upstream the bugreport.
Done. I don't think I'll fix this until it comes in the mainstream package.