* bug#5541: 23.1; after upgrading to emacs-23, meta key in xterm no longer works
@ 2010-02-07 19:55 ` Jim Paris
2010-03-13 18:42 ` Chong Yidong
2010-03-13 19:57 ` Glenn Morris
0 siblings, 2 replies; 9+ messages in thread
From: Jim Paris @ 2010-02-07 19:55 UTC (permalink / raw
To: 5541, jim
With "emacs23 -nw" running inside xterm-253, my meta key does not work
for things like M-x. Instead, the terminal bell beeps, and the string
;120~ appears in the buffer. Looking at the log below, this is
because the terminal actually sent the string \e[27;3;120~ which is
occurring because emacs turned on the "modifyOtherKeys" setting with
the escape sequence \e[>4;1m at startup. Older versions of emacs did
not do this, and everything worked fine.
Indeed, if I execute the command:
(xterm-turn-off-modify-other-keys (selected-frame))
then my meta key temporarily starts working again.
My normal Xterm settings are
xterm*metaSendsEscape: true
xterm*eightBitInput: false
which has always worked in previous versions.
This new "modifyOtherKeys" stuff causes plenty of other problems too,
like the string "0;235;0c" (xterm identification response?) sometimes
appearing in my buffer at startup if the system is heavily loaded or
I'm on a slow connection, and the input buffer getting flushed at
startup, so I lose stuff I typed while emacs was loading. Could a
knob be added to just get rid of it completely?
-jim
In GNU Emacs 23.1.1 (x86_64-pc-linux-gnu, GTK+ Version 2.18.3)
of 2009-11-01 on excelsior, modified by Debian
configured using `configure '--build=x86_64-linux-gnu' '--host=x86_64-linux-gnu' '--prefix=/usr' '--sharedstatedir=/var/lib' '--libexecdir=/usr/lib' '--localstatedir=/var/lib' '--infodir=/usr/share/info' '--mandir=/usr/share/man' '--with-pop=yes' '--enable-locallisppath=/etc/emacs23:/etc/emacs:/usr/local/share/emacs/23.1/site-lisp:/usr/local/share/emacs/site-lisp:/usr/share/emacs/23.1/site-lisp:/usr/share/emacs/site-lisp:/usr/share/emacs/23.1/leim' '--with-x=yes' '--with-x-toolkit=gtk' '--with-toolkit-scroll-bars' 'build_alias=x86_64-linux-gnu' 'host_alias=x86_64-linux-gnu' 'CFLAGS=-DDEBIAN -g -O2' 'LDFLAGS=-g' 'CPPFLAGS=''
Important settings:
value of $LC_ALL: nil
value of $LC_COLLATE: nil
value of $LC_CTYPE: nil
value of $LC_MESSAGES: nil
value of $LC_MONETARY: nil
value of $LC_NUMERIC: nil
value of $LC_TIME: nil
value of $LANG: en_US.UTF-8
value of $XMODIFIERS: nil
locale-coding-system: utf-8-unix
default-enable-multibyte-characters: t
Major mode: Text
Minor modes in effect:
tooltip-mode: t
tool-bar-mode: t
file-name-shadow-mode: t
global-font-lock-mode: t
font-lock-mode: t
global-auto-composition-mode: t
auto-composition-mode: t
auto-encryption-mode: t
auto-compression-mode: t
column-number-mode: t
line-number-mode: t
transient-mark-mode: t
Recent input:
ESC [ > 0 ; 2 3 5 ; 0 c a s d f RET ( x t e r m - t
u r n - o f f - m o d i f y - o t h e r - k e y s SPC
( s e l e c t e d - f r a m e ) ) RET C-x C-s C-g ESC
[ 2 7 ; 3 ; 1 2 0 ~ C-p C-e C-n C-p C-x C-e C-n ESC
x C-g RET RET ESC x r e p o r t - b u g RET C-g ESC
x r e p o t - e m DEL DEL DEL DEL r t - e m a TAB
RET
Recent messages:
Loading /etc/emacs/site-start.d/50psvn.el (source)...done
Loading /etc/emacs/site-start.d/51debian-el.el (source)...done
Loading /etc/emacs/site-start.d/70jim.el (source)...
Toggling menu-bar-mode off; better pass an explicit argument.
Ready.
Loading /etc/emacs/site-start.d/70jim.el (source)...done
Loading quail/latin-ltx...done
Ready.
Quit
nil
Quit [2 times]
^ permalink raw reply [flat|nested] 9+ messages in thread
* bug#5541: 23.1; after upgrading to emacs-23, meta key in xterm no longer works
2010-02-07 19:55 ` bug#5541: 23.1; after upgrading to emacs-23, meta key in xterm no longer works Jim Paris
@ 2010-03-13 18:42 ` Chong Yidong
2010-03-13 19:57 ` Glenn Morris
1 sibling, 0 replies; 9+ messages in thread
From: Chong Yidong @ 2010-03-13 18:42 UTC (permalink / raw
To: emacs-devel; +Cc: Jim Paris, 5541
Does anyone on this list have xterm-253 available to test? I can't
reproduce the problem on xterm 241, and don't have xterm-253 available
to test at the moment.
> With "emacs23 -nw" running inside xterm-253, my meta key does not work
> for things like M-x. Instead, the terminal bell beeps, and the string
> ;120~ appears in the buffer. Looking at the log below, this is
> because the terminal actually sent the string \e[27;3;120~ which is
> occurring because emacs turned on the "modifyOtherKeys" setting with
> the escape sequence \e[>4;1m at startup. Older versions of emacs did
> not do this, and everything worked fine.
>
> Indeed, if I execute the command:
> (xterm-turn-off-modify-other-keys (selected-frame))
> then my meta key temporarily starts working again.
>
> My normal Xterm settings are
> xterm*metaSendsEscape: true
> xterm*eightBitInput: false
> which has always worked in previous versions.
^ permalink raw reply [flat|nested] 9+ messages in thread
* bug#5541: 23.1; after upgrading to emacs-23, meta key in xterm no longer works
[not found] <873a04ysew.fsf@stupidchicken.com>
2010-02-07 19:55 ` bug#5541: 23.1; after upgrading to emacs-23, meta key in xterm no longer works Jim Paris
@ 2010-03-13 19:10 ` Sven Joachim
[not found] ` <xdk4tggfk7.fsf@fencepost.gnu.org>
2 siblings, 0 replies; 9+ messages in thread
From: Sven Joachim @ 2010-03-13 19:10 UTC (permalink / raw
To: Chong Yidong; +Cc: Jim Paris, emacs-devel, 5541
On 2010-03-13 19:42 +0100, Chong Yidong wrote:
> Does anyone on this list have xterm-253 available to test? I can't
> reproduce the problem on xterm 241, and don't have xterm-253 available
> to test at the moment.
With xterm 255 I cannot reproduce the problem either (xterm 253 is not
available here).
Sven
>> With "emacs23 -nw" running inside xterm-253, my meta key does not work
>> for things like M-x. Instead, the terminal bell beeps, and the string
>> ;120~ appears in the buffer. Looking at the log below, this is
>> because the terminal actually sent the string \e[27;3;120~ which is
>> occurring because emacs turned on the "modifyOtherKeys" setting with
>> the escape sequence \e[>4;1m at startup. Older versions of emacs did
>> not do this, and everything worked fine.
>>
>> Indeed, if I execute the command:
>> (xterm-turn-off-modify-other-keys (selected-frame))
>> then my meta key temporarily starts working again.
>>
>> My normal Xterm settings are
>> xterm*metaSendsEscape: true
>> xterm*eightBitInput: false
>> which has always worked in previous versions.
^ permalink raw reply [flat|nested] 9+ messages in thread
* bug#5541: 23.1; after upgrading to emacs-23, meta key in xterm no longer works
2010-02-07 19:55 ` bug#5541: 23.1; after upgrading to emacs-23, meta key in xterm no longer works Jim Paris
2010-03-13 18:42 ` Chong Yidong
@ 2010-03-13 19:57 ` Glenn Morris
1 sibling, 0 replies; 9+ messages in thread
From: Glenn Morris @ 2010-03-13 19:57 UTC (permalink / raw
To: Chong Yidong; +Cc: Jim Paris, emacs-devel, 5541
Chong Yidong wrote:
> Does anyone on this list have xterm-253 available to test?
Yes.
>> With "emacs23 -nw" running inside xterm-253, my meta key does not work
>> for things like M-x. Instead, the terminal bell beeps, and the string
>> ;120~ appears in the buffer.
Something similar happens for me too (and with the trunk).
>> Indeed, if I execute the command:
>> (xterm-turn-off-modify-other-keys (selected-frame))
>> then my meta key temporarily starts working again.
This command makes no difference for me.
I normally use aterm, which works fine.
^ permalink raw reply [flat|nested] 9+ messages in thread
* bug#5541: 23.1; after upgrading to emacs-23, meta key in xterm no longer works
[not found] ` <xdk4tggfk7.fsf@fencepost.gnu.org>
@ 2010-03-13 20:29 ` Chong Yidong
[not found] ` <876350rmmx.fsf@stupidchicken.com>
1 sibling, 0 replies; 9+ messages in thread
From: Chong Yidong @ 2010-03-13 20:29 UTC (permalink / raw
To: Glenn Morris; +Cc: Jim Paris, 5541, emacs-devel
Glenn Morris <rgm@gnu.org> writes:
>> Does anyone on this list have xterm-253 available to test?
>
> Yes.
>
>>> With "emacs23 -nw" running inside xterm-253, my meta key does not work
>>> for things like M-x. Instead, the terminal bell beeps, and the string
>>> ;120~ appears in the buffer.
>
> Something similar happens for me too (and with the trunk).
And does xterm-24* behave OK?
It's possible this is a bug in xterm-253, which would be why Sven
Joachim does not see it on xterm-255.
^ permalink raw reply [flat|nested] 9+ messages in thread
* bug#5541: 23.1; after upgrading to emacs-23, meta key in xterm no longer works
[not found] ` <876350rmmx.fsf@stupidchicken.com>
@ 2010-03-13 22:09 ` Jim Paris
[not found] ` <20100313220934.GA23155@psychosis.jim.sh>
2010-03-14 19:05 ` Glenn Morris
2 siblings, 0 replies; 9+ messages in thread
From: Jim Paris @ 2010-03-13 22:09 UTC (permalink / raw
To: Chong Yidong; +Cc: 5541, dickey, emacs-devel
Chong Yidong wrote:
> Glenn Morris <rgm@gnu.org> writes:
>
> >> Does anyone on this list have xterm-253 available to test?
> >
> > Yes.
> >
> >>> With "emacs23 -nw" running inside xterm-253, my meta key does not work
> >>> for things like M-x. Instead, the terminal bell beeps, and the string
> >>> ;120~ appears in the buffer.
> >
> > Something similar happens for me too (and with the trunk).
>
> And does xterm-24* behave OK?
>
> It's possible this is a bug in xterm-253, which would be why Sven
> Joachim does not see it on xterm-255.
I did some more testing and it only happens on some of my systems.
Turns out the problem shows up when this .Xresources setting is
present:
! Shift-paste to paste CLIPBOARD instead of PRIMARY.
xterm*VT100.Translations: #override \
Shift <Btn2Up>: insert-selection(CLIPBOARD)\n \
Ctrl ~Shift Meta <Key>-: smaller-vt-font() \n \
Ctrl ~Shift Meta <Key>=: larger-vt-font() \n
That's worked for me forever... I have no idea why it would cause new
versions of emacs to act funny. CCing Thomas Dickey, any ideas?
The original report is at http://debbugs.gnu.org/cgi/bugreport.cgi?bug=5541
-jim
^ permalink raw reply [flat|nested] 9+ messages in thread
* bug#5541: 23.1; after upgrading to emacs-23, meta key in xterm no longer works
[not found] ` <20100313220934.GA23155@psychosis.jim.sh>
@ 2010-03-13 23:57 ` Thomas Dickey
[not found] ` <20100313182742.U88710@mail101.his.com>
1 sibling, 0 replies; 9+ messages in thread
From: Thomas Dickey @ 2010-03-13 23:57 UTC (permalink / raw
To: Jim Paris; +Cc: Chong Yidong, 5541, dickey, emacs-devel
On Sat, 13 Mar 2010, Jim Paris wrote:
> Chong Yidong wrote:
>> Glenn Morris <rgm@gnu.org> writes:
>>
>>>> Does anyone on this list have xterm-253 available to test?
>>>
>>> Yes.
>>>
>>>>> With "emacs23 -nw" running inside xterm-253, my meta key does not work
>>>>> for things like M-x. Instead, the terminal bell beeps, and the string
>>>>> ;120~ appears in the buffer.
>>>
>>> Something similar happens for me too (and with the trunk).
>>
>> And does xterm-24* behave OK?
>>
>> It's possible this is a bug in xterm-253, which would be why Sven
>> Joachim does not see it on xterm-255.
>
> I did some more testing and it only happens on some of my systems.
> Turns out the problem shows up when this .Xresources setting is
> present:
>
> ! Shift-paste to paste CLIPBOARD instead of PRIMARY.
> xterm*VT100.Translations: #override \
> Shift <Btn2Up>: insert-selection(CLIPBOARD)\n \
> Ctrl ~Shift Meta <Key>-: smaller-vt-font() \n \
> Ctrl ~Shift Meta <Key>=: larger-vt-font() \n
>
> That's worked for me forever... I have no idea why it would cause new
> versions of emacs to act funny. CCing Thomas Dickey, any ideas?
> The original report is at http://debbugs.gnu.org/cgi/bugreport.cgi?bug=5541
The various key-modifier resources are all ifdef'd as a single group
(no escape sequence is implemented to disable the feature). I suppose
emacs is checking the version number from xterm to decide if the feature
is present, since there's no other indication that it's available.
xterm generally doesn't know what the translations do, but it does check
if the meta key appears in a translation. For that, and alt, xterm
decides to not use those in modified function-keys - to try to avoid odd
conflicts with cases such as this translation. (They may be the same key
- same general effect). But the particular combination caught by the
translations wouldn't be seen by xterm; it only massages the seen
keycodes.
The escape sequence says xterm's sending a 3 (for alt). Perhaps it's
something along the lines of xterm deciding that meta isn't part of the
modify-other-keys feature, but alt (on the same key) still is. I assume
that emacs is looking for 9 (meta) rather than 3 (alt), and so it errors
out.
--
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net
^ permalink raw reply [flat|nested] 9+ messages in thread
* bug#5541: 23.1; after upgrading to emacs-23, meta key in xterm no longer works
[not found] ` <876350rmmx.fsf@stupidchicken.com>
2010-03-13 22:09 ` Jim Paris
[not found] ` <20100313220934.GA23155@psychosis.jim.sh>
@ 2010-03-14 19:05 ` Glenn Morris
2 siblings, 0 replies; 9+ messages in thread
From: Glenn Morris @ 2010-03-14 19:05 UTC (permalink / raw
To: Chong Yidong; +Cc: Jim Paris, 5541, emacs-devel
Chong Yidong wrote:
> And does xterm-24* behave OK?
I don't have that version. My system just updated to xterm-255, and it
behaves the same as 253 did. Running `xrdb -remove' first makes no
difference.
^ permalink raw reply [flat|nested] 9+ messages in thread
* bug#5541: 23.1; after upgrading to emacs-23, meta key in xterm no longer works
[not found] ` <20100313182742.U88710@mail101.his.com>
@ 2010-03-19 15:19 ` Chong Yidong
0 siblings, 0 replies; 9+ messages in thread
From: Chong Yidong @ 2010-03-19 15:19 UTC (permalink / raw
To: Thomas Dickey; +Cc: Jim Paris, dickey, 5541
Thomas Dickey <dickey@his.com> writes:
>> ! Shift-paste to paste CLIPBOARD instead of PRIMARY.
>> xterm*VT100.Translations: #override \
>> Shift <Btn2Up>: insert-selection(CLIPBOARD)\n \
>> Ctrl ~Shift Meta <Key>-: smaller-vt-font() \n \
>> Ctrl ~Shift Meta <Key>=: larger-vt-font() \n
>
> The various key-modifier resources are all ifdef'd as a single group
> (no escape sequence is implemented to disable the feature). I suppose
> emacs is checking the version number from xterm to decide if the feature
> is present, since there's no other indication that it's available.
>
> xterm generally doesn't know what the translations do, but it does
> check if the meta key appears in a translation. For that, and alt,
> xterm decides to not use those in modified function-keys - to try to
> avoid odd conflicts with cases such as this translation. (They may be
> the same key - same general effect). But the particular combination
> caught by the translations wouldn't be seen by xterm; it only massages
> the seen keycodes.
>
> The escape sequence says xterm's sending a 3 (for alt). Perhaps it's
> something along the lines of xterm deciding that meta isn't part of
> the modify-other-keys feature, but alt (on the same key) still is. I
> assume that emacs is looking for 9 (meta) rather than 3 (alt), and so
> it errors out.
Thanks for the explanation. I don't see, from this, what we can do to
detect and fix this problem automatically, so I suppose it will be up to
the user who has defined such translations to tell Emacs not to use
modify-other-keys. I have added an entry to etc/PROBLEMS in the Emacs
source tree documenting this.
^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2010-03-19 15:19 UTC | newest]
Thread overview: 9+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <873a04ysew.fsf@stupidchicken.com>
2010-02-07 19:55 ` bug#5541: 23.1; after upgrading to emacs-23, meta key in xterm no longer works Jim Paris
2010-03-13 18:42 ` Chong Yidong
2010-03-13 19:57 ` Glenn Morris
2010-03-13 19:10 ` Sven Joachim
[not found] ` <xdk4tggfk7.fsf@fencepost.gnu.org>
2010-03-13 20:29 ` Chong Yidong
[not found] ` <876350rmmx.fsf@stupidchicken.com>
2010-03-13 22:09 ` Jim Paris
[not found] ` <20100313220934.GA23155@psychosis.jim.sh>
2010-03-13 23:57 ` Thomas Dickey
[not found] ` <20100313182742.U88710@mail101.his.com>
2010-03-19 15:19 ` Chong Yidong
2010-03-14 19:05 ` Glenn Morris
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).