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.
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 described above.
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 terminals?
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.