Red Hat Bugzilla – Bug 126857
alt+[0-9] do not work in irssi
Last modified: 2007-11-30 17:10:45 EST
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):
Steps to Reproduce:
1. start xterm
2. execute `irssi`
3. type in '/window new' - your screen should not be split into two
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.
The following X resource seems to fix this problem:
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
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.
Ok, xterm-200-6 is now available with the "eightBitInput: False" change.
Setting status to "RAWHIDE"