Bug 126857 - alt+[0-9] do not work in irssi
Summary: alt+[0-9] do not work in irssi
Alias: None
Product: Fedora
Classification: Fedora
Component: xterm
Version: rawhide
Hardware: i686
OS: Linux
Target Milestone: ---
Assignee: Mike A. Harris
QA Contact:
Depends On:
TreeView+ depends on / blocked
Reported: 2004-06-28 14:08 UTC by Stuart Children
Modified: 2007-11-30 22:10 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2005-04-16 17:22:24 UTC
Type: ---

Attachments (Terms of Use)

Description Stuart Children 2004-06-28 14:08:38 UTC
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):

How reproducible:

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.

Additional info:

The following X resource seems to fix this problem:

xterm*metaSendsEscape: true

Comment 1 Thomas E. Dickey 2004-07-14 00:28:12 UTC
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.

Comment 2 Thomas E. Dickey 2004-07-24 14:28:03 UTC
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).

Comment 3 Mike A. Harris 2005-04-16 16:35:11 UTC
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.


Comment 4 Mike A. Harris 2005-04-16 17:22:24 UTC
Ok, xterm-200-6 is now available with the "eightBitInput: False" change.

Setting status to "RAWHIDE"

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