From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040510 Description of problem: In an xterm, Alt+[0-9] codes are not sent through to irssi. Version-Release number of selected component (if applicable): xterm-191-1 How reproducible: Always Steps to Reproduce: 1. start xterm 2. execute `irssi` 3. type in '/window new' - your screen should not be split into two windows 4. try to switch from one to the other by pressing 'Alt+1' and 'Alt+2' Actual Results: No effect to irssi. Odd characters are printed (on one machine, these appeared to be decimal values 177 and 178 for Alt+1 and Alt+2 respectively). Expected Results: Focus in irssi should switch between the two windows. Additional info: The following X resource seems to fix this problem: xterm*metaSendsEscape: true
The problem with metaSendsEscape is that not everyone happens to have meta- and alt- assigned to the same key. So it would probably be a mistake to make it a default.
I'm still thinking about this one (trying to not get it confused with the broken key-modifiers in Debian's unstable). The user wants to have escape characters sent before function keys, but that feature is normally turned off when the eightBitInput resource is set (as it should be for UTF-8 locales).
There have been various bug reports reported against xterm in the last few years of which setting "metaSendsEscape: true" solves, or setting "eightBitInput: False" solves. However, setting either of those options has side effects that cause a change in behaviour for someone else, who then files a bug report asking to have the default changed to something else. This presents us with a dilemma. The "you can't please everyone, because they have conflicting goals/preferences" dilemma. Our goal is rather to provide a sane set of defaults that works for the general case for most users, and let users reconfigure things themselves in their local configuration if the default does not meet their personal needs. This is of course why applications like xterm have options - because different users have different needs. We are setting "eightBitInput: False" to fix some other problems, as this is the solution we used to have in our rpms. Hopefully it will fix this problem also. I'll update the report again once we have the new rpms built. Thanks.
Ok, xterm-200-6 is now available with the "eightBitInput: False" change. Setting status to "RAWHIDE"