Bug 30872 - Meta-Delete on tty causes unhandled suspend
Meta-Delete on tty causes unhandled suspend
Status: CLOSED DEFERRED
Product: Red Hat Linux
Classification: Retired
Component: xemacs (Show other bugs)
7.0
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Trond Eivind Glomsrxd
Aaron Brown
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2001-03-06 17:01 EST by Brandon Craig Rhodes
Modified: 2007-04-18 12:32 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2001-03-08 17:05:15 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Brandon Craig Rhodes 2001-03-06 17:01:51 EST
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).

Reproducible: Always
Steps to Reproduce:
1. Start XEmacs with the -nw option so it uses your tty rather than an X
window.
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
your return.
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.
Comment 1 Trond Eivind Glomsrxd 2001-03-06 17:11:20 EST
Which version of xemacs are you running?
Comment 2 Brandon Craig Rhodes 2001-03-06 18:01:17 EST
Sorry; version is xemacs-21.1.12-3.
Comment 3 Trond Eivind Glomsrxd 2001-03-06 18:12:25 EST
Please update your system with up2date, and try it again: 21.1.14-2.7 is the
newest release for RHL 7.
Comment 4 Brandon Craig Rhodes 2001-03-06 18:47:08 EST
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
described above.
Comment 5 Trond Eivind Glomsrxd 2001-03-06 19:01:14 EST
OK... I couldn't reproduce it properly here, will look closer into it later.
Comment 6 Brandon Craig Rhodes 2001-03-06 19:26:26 EST
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
terminals?
Comment 7 Trond Eivind Glomsrxd 2001-03-08 16:39:29 EST
OK, I can reproduce it here...  I'll upstream the bugreport.
Comment 8 Trond Eivind Glomsrxd 2001-03-08 17:05:11 EST
Done. I don't think I'll fix this until it comes in the mainstream package.

Note You need to log in before you can comment on or make changes to this bug.