Bug 126857 - alt+[0-9] do not work in irssi
alt+[0-9] do not work in irssi
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: xterm (Show other bugs)
rawhide
i686 Linux
medium Severity medium
: ---
: ---
Assigned To: Mike A. Harris
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2004-06-28 10:08 EDT by Stuart Children
Modified: 2007-11-30 17:10 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-04-16 13:22:24 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Stuart Children 2004-06-28 10:08:38 EDT
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
Comment 1 Thomas E. Dickey 2004-07-13 20:28:12 EDT
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 10:28:03 EDT
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 12:35:11 EDT
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.
Comment 4 Mike A. Harris 2005-04-16 13:22:24 EDT
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.