Processed: Re: Bug#260232: xterm: XTerm*metaSendsEscape no longer working
Processing commands for [EMAIL PROTECTED]: retitle 256706 xlibs: attaching multiple modifiers to the same key wreaks havoc; breaks Win+Tab switching in many window managers Bug#256706: xlibs: Win+Tab switching broken in many window managers Changed Bug title. retitle 260232 xlibs: modifier madness breaks XTerm*metaSendsEscape Bug#260232: xterm: XTerm*metaSendsEscape no longer working Changed Bug title. reassign 260232 xlibs Bug#260232: xlibs: modifier madness breaks XTerm*metaSendsEscape Bug reassigned from package `xterm' to `xlibs'. severity 260232 serious Bug#260232: xlibs: modifier madness breaks XTerm*metaSendsEscape Severity set to `serious'. merge 256706 260232 Bug#256706: xlibs: attaching multiple modifiers to the same key wreaks havoc; breaks Win+Tab switching in many window managers Bug#260232: xlibs: modifier madness breaks XTerm*metaSendsEscape Bug#259740: xlibs: Windows key no longer treated as modifer, just as Super_L Merged 256706 259740 260232. On Tue, Jul 27, 2004 at 11:41:23AM +0200, Guido Guenther wrote: Unknown command or malformed arguments to command. Hi, Unknown command or malformed arguments to command. On Tue, Jul 27, 2004 at 01:39:40AM -0500, Branden Robinson wrote: Unknown command or malformed arguments to command. Try downgrading xlibs to 4.3.0.dfsg.1-4. Unknown command or malformed arguments to command. Unknown command or malformed arguments to command. Too many unknown commands, stopping here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database)
Bug#260232: xterm: XTerm*metaSendsEscape no longer working
retitle 256706 xlibs: attaching multiple modifiers to the same key wreaks havoc; breaks Win+Tab switching in many window managers retitle 260232 xlibs: modifier madness breaks XTerm*metaSendsEscape reassign 260232 xlibs severity 260232 serious merge 256706 260232 On Tue, Jul 27, 2004 at 11:41:23AM +0200, Guido Guenther wrote: Hi, On Tue, Jul 27, 2004 at 01:39:40AM -0500, Branden Robinson wrote: Try downgrading xlibs to 4.3.0.dfsg.1-4. If that fixes it, this bug is the probably the same as #256706. Downgrading to the above version fixes it. Thanks for the feedback! I'm merging this bug with an identical issue. -- G. Branden Robinson| Debian GNU/Linux | Please do not look directly into [EMAIL PROTECTED] | laser with remaining eye. http://people.debian.org/~branden/ | signature.asc Description: Digital signature
Processed: Re: Bug#260232: xterm: XTerm*metaSendsEscape no longer working
Processing commands for [EMAIL PROTECTED]: tag 260232 + moreinfo Bug#260232: xterm: XTerm*metaSendsEscape no longer working There were no tags set. Tags added: moreinfo thanks Stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database)
Bug#260232: xterm: XTerm*metaSendsEscape no longer working
tag 260232 + moreinfo thanks On Mon, Jul 19, 2004 at 04:06:28PM +0200, Guido Guenther wrote: Package: xterm Version: 4.3.0.dfsg.1-6 Severity: normal Hi, the above is no longer working after an upgrade to the versions below. Before that I could use: Alt-f, Alt-b to jump whole words forward or backward in a bash running within xterm. This doesn't work anymore, ESC-f, ESC-b still works though. Any ideas where to start digging? Cheers, -- Guido P.S.: I'm additionally using: keysym Alt_L = Meta_L Alt_L to make the above work. Try downgrading xlibs to 4.3.0.dfsg.1-4. If that fixes it, this bug is the probably the same as #256706. -- G. Branden Robinson|I just wanted to see what it looked Debian GNU/Linux |like in a spotlight. [EMAIL PROTECTED] |-- Jim Morrison http://people.debian.org/~branden/ | signature.asc Description: Digital signature
Bug#260232: xterm: XTerm*metaSendsEscape no longer working
Hi, On Tue, Jul 27, 2004 at 01:39:40AM -0500, Branden Robinson wrote: Try downgrading xlibs to 4.3.0.dfsg.1-4. If that fixes it, this bug is the probably the same as #256706. Downgrading to the above version fixes it. Cheers, -- Guido signature.asc Description: Digital signature
Bug#260232: xterm: XTerm*metaSendsEscape no longer working
Hi Thomas, On Tue, Jul 20, 2004 at 08:50:53PM -0400, Thomas Dickey wrote: shift Shift_L (0x32), Shift_R (0x3e) lockCaps_Lock (0x42) control Control_L (0x25), Control_R (0x6d) mod1Meta_L (0x40), Alt_R (0x71) mod2Num_Lock (0x4d) mod3 mod4Super_L (0x73), Super_R (0x74) mod5 Mine always looked like this: xmodmap: up to 2 keys per modifier, (keycodes in parentheses): shift Shift_L (0x32), Shift_R (0x3e) lockCaps_Lock (0x42) control Control_L (0x25), Control_R (0x6d) mod1Meta_L (0x40), Alt_R (0x71) mod2Num_Lock (0x4d) mod3 mod4Multi_key (0x73), Meta_R (0x74) mod5Scroll_Lock (0x77) which looks sane to me. Here's the (maybe) interesting part: When I press ALT, I see: Input keysym 0xFFE7, 0:'' 7bit Handle 7bit-key But when I then press f (while holding down ALT) no output appears in the log at all, although I have: meta_left mask 0x8 is Mod1 modifier alt_right mask 0x8 is Mod1 modifier num_lock mask 0x10 is Mod2 modifier meta_right mask 0x40 is Mod4 modifier in my logs, which looks also okay to me. Puzzled, -- Guido signature.asc Description: Digital signature
Bug#260232: xterm: XTerm*metaSendsEscape no longer working
On Wed, Jul 21, 2004 at 11:19:30AM +0200, Guido Guenther wrote: Hi Thomas, On Tue, Jul 20, 2004 at 08:50:53PM -0400, Thomas Dickey wrote: shift Shift_L (0x32), Shift_R (0x3e) lockCaps_Lock (0x42) control Control_L (0x25), Control_R (0x6d) mod1Meta_L (0x40), Alt_R (0x71) mod2Num_Lock (0x4d) mod3 mod4Super_L (0x73), Super_R (0x74) mod5 Mine always looked like this: yes (am not at home, but from memory): your Meta_L looks like my Alt_L before I reassigned it. Reading last night, I see some comments that give me the impression that the order of definition (i.e., which xmodmap command was done first) is the problem, that the last one is the one that takes effect. I've seen a few comments by Branden Robinson which seem to indicate that some change has been made in the keyboard configuration (perhaps that's related to this). I'm cc'ing him to see if he has any insight on this. When I started looking into this a week ago, I could see that (for my keyboard at least), the left/right Alt keys are used for the cases where the *VT100.translations resource says Meta. Looking at the X library code, that seems consistent. Google finds a large number of comments that indicate that Alt and Meta have been used almost interchangeably, and that depending on the keyboard configuration they're sometimes just interchanged at the whim of the person doing the keyboard support. xmodmap: up to 2 keys per modifier, (keycodes in parentheses): shift Shift_L (0x32), Shift_R (0x3e) lockCaps_Lock (0x42) control Control_L (0x25), Control_R (0x6d) mod1Meta_L (0x40), Alt_R (0x71) mod2Num_Lock (0x4d) mod3 mod4Multi_key (0x73), Meta_R (0x74) mod5Scroll_Lock (0x77) which looks sane to me. Here's the (maybe) interesting part: When I press ALT, I see: Input keysym 0xFFE7, 0:'' 7bit Handle 7bit-key Is that ALT the same as one of your Meta_L or Alt_R keys? xev could identify that. What your trace seems to indicate to me is that the mod1 for Meta_L isn't having a real effect, so the literal key is sent to xterm. That should show up in xev's trace (though xev doesn't show the modifier information, it should show a Alt_L or Meta_L). But when I then press f (while holding down ALT) no output appears in the log at all, although I have: meta_left mask 0x8 is Mod1 modifier alt_right mask 0x8 is Mod1 modifier num_lock mask 0x10 is Mod2 modifier meta_right mask 0x40 is Mod4 modifier in my logs, which looks also okay to me. Puzzled, -- Guido -- Thomas E. Dickey http://invisible-island.net ftp://invisible-island.net pgpWoHrfPKaT0.pgp Description: PGP signature
Bug#260232: xterm: XTerm*metaSendsEscape no longer working
On Wed, Jul 21, 2004 at 05:44:32AM -0400, Thomas Dickey wrote: which looks sane to me. Here's the (maybe) interesting part: When I press ALT, I see: Input keysym 0xFFE7, 0:'' 7bit Handle 7bit-key Is that ALT the same as one of your Meta_L or Alt_R keys? I mean the key labeled alt on the keyboard. On my Mac Keyboard: keycode 64, keysym 0xffe7. It has the modifier ALT_L assigned by default and I change that via: keysym Alt_L = Meta_L Alt_L which works according to xev. xev could identify that. What your trace seems to indicate to me is that the mod1 for Meta_L isn't having a real effect, so the literal key is sent to xterm. That should show up in xev's trace (though xev doesn't show the modifier information, it should show a Alt_L or Meta_L). When I do: xmodmap -e 'keycode 64 = Alt_L' (removing the Meta_L) *it works* again. So it seems it's actually not Meta sends escape anymore but rather Alt sends escape. This is a change in behaviour which we should at least document somewhere in the debian package before closing the bug. I'm still having some problems with my apple-key-click = middle click emulation, which completely confuses xterm at the moment (and which showed up at the same time than the above problem), but I'll have to dig deeper into this before reporting this as a bug. Thanks _very_ much for your help, -- Guido signature.asc Description: Digital signature
Bug#260232: xterm: XTerm*metaSendsEscape no longer working
On Wed, Jul 21, 2004 at 09:49:08AM -0400, Thomas Dickey wrote: ok. I don't see anyplace in xterm that I could improve on here (since it sees only one of the alt/meta definitions). There is some provision for keys having more than one name and modifier (which may have issues to resolve). Does gnome-terminal still work if you remove the definition for Meta_L? Yes. -- Guido signature.asc Description: Digital signature
Bug#260232: xterm: XTerm*metaSendsEscape no longer working
On Wed, Jul 21, 2004 at 03:14:07PM +0200, Guido Guenther wrote: On Wed, Jul 21, 2004 at 05:44:32AM -0400, Thomas Dickey wrote: which looks sane to me. Here's the (maybe) interesting part: When I press ALT, I see: Input keysym 0xFFE7, 0:'' 7bit Handle 7bit-key Is that ALT the same as one of your Meta_L or Alt_R keys? I mean the key labeled alt on the keyboard. On my Mac Keyboard: keycode 64, keysym 0xffe7. It has the modifier ALT_L assigned by default and I change that via: keysym Alt_L = Meta_L Alt_L which works according to xev. ok - that (difference in PC versus other keyboards) was one of the comments that google found which illustrates the alt/meta issue. xev could identify that. What your trace seems to indicate to me is that the mod1 for Meta_L isn't having a real effect, so the literal key is sent to xterm. That should show up in xev's trace (though xev doesn't show the modifier information, it should show a Alt_L or Meta_L). When I do: xmodmap -e 'keycode 64 = Alt_L' (removing the Meta_L) *it works* again. So it seems it's actually not Meta sends escape anymore but rather Alt sends escape. ok. I don't see anyplace in xterm that I could improve on here (since it sees only one of the alt/meta definitions). There is some provision for keys having more than one name and modifier (which may have issues to resolve). Does gnome-terminal still work if you remove the definition for Meta_L? This is a change in behaviour which we should at least document somewhere in the debian package before closing the bug. I'm still having some problems with my apple-key-click = middle click emulation, which completely confuses xterm at the moment (and which showed up at the same time than the above problem), but I'll have to dig deeper into this before reporting this as a bug. Thanks _very_ much for your help, no problem (though it doesn't seem that it's solved yet) -- Thomas E. Dickey http://invisible-island.net ftp://invisible-island.net pgpl9oqklZqeg.pgp Description: PGP signature
Bug#260232: xterm: XTerm*metaSendsEscape no longer working
On Wed, Jul 21, 2004 at 05:44:32AM -0400, Thomas Dickey wrote: I've seen a few comments by Branden Robinson which seem to indicate that some change has been made in the keyboard configuration (perhaps that's related to this). I'm cc'ing him to see if he has any insight on this. Yes; it's a long, complex story. Basically, in 4.3.0.dfsg.1-5 we backported from XFree86 CVS a fix by Ivan Pascal for problems with modifier keys when using multiple keyboard layouts at once. A kludge to restore the most grievously affected functionality was applied in -6, but a real fix is still forthcoming. The details are absurdly technical (and in part have to do with a lot of clients using only core X protocol functions for querying the keyboard despite this XKB era), and I don't have a full command of them myself, but I think I know what to do to make some better headway. I've begun consulting with Ivan Pascal on this subject, and he's been quite helpful. -- G. Branden Robinson| I am only good at complaining. Debian GNU/Linux | You don't want me near your code. [EMAIL PROTECTED] | -- Dan Jacobson http://people.debian.org/~branden/ | signature.asc Description: Digital signature
Bug#260232: xterm: XTerm*metaSendsEscape no longer working
On Mon, Jul 19, 2004 at 04:24:08PM -0400, Thomas Dickey wrote: I don't think the problem is within xterm (it's been a while since I tweaked the logic for this). More likely something in the keyboard configuration has separated the definitions that you were relying upon. What I do to debug this is to use xev and ensure that it's reporting Meta_L for the key. If that's right, I generally compile a debug version of xterm It is. I already checked this before sending the report. (configure --enable-trace) and check the initialization of the modifiers. Thanks, I'll try that. As a related problem mouse button emulation also stopped working in xterm. Mouseemu is a user space programm using the kernel's /dev/input/event layer to emulate say right mouseclicks using e.g. CTRL-left click. This still works in GTK based apps but no longer in xterm. I don't intend to mix bug reports here, but showed up at the same time and is also related to modifier keys. Cheers, -- Guido
Bug#260232: xterm: XTerm*metaSendsEscape no longer working
Hi Thomas, On Mon, Jul 19, 2004 at 02:58:34PM -0400, Thomas Dickey wrote: the above is no longer working after an upgrade to the versions below. Before that I could use: Alt-f, Alt-b to jump whole words forward or backward in a bash running within xterm. This doesn't work anymore, ESC-f, ESC-b still works though. Any ideas where to start digging? man xterm metaSendsEscape I'm not sure I understand this. I have this on, and it stopped working recently, I can't find any hint in the manpage, for the cause of this. Cheers, -- Guido
Bug#260232: xterm: XTerm*metaSendsEscape no longer working
On Mon, Jul 19, 2004 at 04:24:08PM -0400, Thomas Dickey wrote: I don't think the problem is within xterm (it's been a while since I tweaked the logic for this). More likely something in the keyboard configuration has separated the definitions that you were relying upon. What I do to debug this is to use xev and ensure that it's reporting Meta_L for the key. If that's right, I generally compile a debug version of xterm (configure --enable-trace) and check the initialization of the modifiers. Trace says about Meta: ~MetaKeyPress: insert-seven-bit() MetaKeyPress: insert-eight-bit() ~MetaButtonPress1: select-start() Button1~MetaMotionNotify: select-extend() ~Ctrl~MetaButtonPress2: ignore() MetaButtonPress2: clear-saved-lines() ~Ctrl~MetaButtonRelease2: insert-selection(PRIMARY, CUT_BUFFER0) ~Ctrl~MetaButtonPress3: start-extend() Button3~MetaMotionNotify: select-extend() ~MetaKeyPress: insert-seven-bit() MetaKeyPress: insert-eight-bit() ~MetaButtonPress1: select-start() Button1~MetaMotionNotify: select-extend() ~Ctrl~MetaButtonPress2: ignore() MetaButtonPress2: clear-saved-lines() ~Ctrl~MetaButtonRelease2: insert-selection(PRIMARY, CUT_BUFFER0) ~Ctrl~MetaButtonPress3: start-extend() Button3~MetaMotionNotify: select-extend() Anything else I can provide? Cheers, -- Guido signature.asc Description: Digital signature
Bug#260232: xterm: XTerm*metaSendsEscape no longer working
On Tue, Jul 20, 2004 at 09:13:59AM +0200, Guido Guenther wrote: On Mon, Jul 19, 2004 at 04:24:08PM -0400, Thomas Dickey wrote: I don't think the problem is within xterm (it's been a while since I tweaked the logic for this). More likely something in the keyboard configuration has separated the definitions that you were relying upon. What I do to debug this is to use xev and ensure that it's reporting Meta_L for the key. If that's right, I generally compile a debug version of xterm (configure --enable-trace) and check the initialization of the modifiers. Trace says about Meta: ~MetaKeyPress: insert-seven-bit() Trace-parent.out has a lot of information - the fragment you're showing tells what it can find about the translations resource. The piece I'm interested in corresponds to the xmodmap settings, e.g., (starting with VTInitModifiers): looking for style 'Root' VTInitModifiers alt_left mask 0x8 is Mod1 modifier alt_right mask 0x8 is Mod1 modifier TranslationsUseKeyword(7ac10):#override xterm looks to see which modifiers are associated with the Alt, Meta and NumLock keys so that when it gets a keypress event, it can look at the modifier information in that event and determine which of those keys might have been used for modifying the key. (Technically, I should also look for the control and shift keys, but it is unusual for someone to change _those_ with xmodmap). In the example I just gave, there's no Meta key associated with a modifier - so metaSendsEscape wouldn't work. The trace is there of course for debugging - it's also possible that xterm would find the modifiers but do something unexpected with them. All of the logic dealing with the modifiers is in input.c, so it's not hard to follow... -- Thomas E. Dickey http://invisible-island.net ftp://invisible-island.net pgpy3L3QYYAHx.pgp Description: PGP signature
Bug#260232: xterm: XTerm*metaSendsEscape no longer working
On Tue, Jul 20, 2004 at 05:38:21AM -0400, Thomas Dickey wrote: looking for style 'Root' VTInitModifiers alt_left mask 0x8 is Mod1 modifier alt_right mask 0x8 is Mod1 modifier TranslationsUseKeyword(7ac10):#override Mine says: VTInitModifiers meta_left mask 0x8 is Mod1 modifier alt_right mask 0x8 is Mod1 modifier num_lock mask 0x10 is Mod2 modifier meta_right mask 0x40 is Mod4 modifier Which looks sane as far as I can tell. I don't think that this helps much, but it seems that gnome-terminal still handels this correctly. Let me know if I can provide any more interesting data. Cheers, -- Guido signature.asc Description: Digital signature
Bug#260232: xterm: XTerm*metaSendsEscape no longer working
On Tue, Jul 20, 2004 at 01:10:56PM +0200, Guido Guenther wrote: On Tue, Jul 20, 2004 at 05:38:21AM -0400, Thomas Dickey wrote: looking for style 'Root' VTInitModifiers alt_left mask 0x8 is Mod1 modifier alt_right mask 0x8 is Mod1 modifier TranslationsUseKeyword(7ac10):#override Mine says: VTInitModifiers meta_left mask 0x8 is Mod1 modifier alt_right mask 0x8 is Mod1 modifier num_lock mask 0x10 is Mod2 modifier meta_right mask 0x40 is Mod4 modifier Which looks sane as far as I can tell. I don't think that this helps much, but it seems that gnome-terminal still handels this correctly. Let me know if I can provide any more interesting data. for now that looks like enough - I'll look closer when I get home (and can look up the history of that slice of code). Just reading the source right now, I do see a couple of things to investigate. -- Thomas E. Dickey http://invisible-island.net ftp://invisible-island.net pgp1A6JXMp3nx.pgp Description: PGP signature
Bug#260232: xterm: XTerm*metaSendsEscape no longer working
On Tue, Jul 20, 2004 at 01:10:56PM +0200, Guido Guenther wrote: On Tue, Jul 20, 2004 at 05:38:21AM -0400, Thomas Dickey wrote: looking for style 'Root' VTInitModifiers alt_left mask 0x8 is Mod1 modifier alt_right mask 0x8 is Mod1 modifier TranslationsUseKeyword(7ac10):#override Mine says: VTInitModifiers meta_left mask 0x8 is Mod1 modifier alt_right mask 0x8 is Mod1 modifier num_lock mask 0x10 is Mod2 modifier meta_right mask 0x40 is Mod4 modifier Which looks sane as far as I can tell. I don't think that this helps much, but it seems that gnome-terminal still handels this correctly. Let me know if I can provide any more interesting data. One possibility (which I read on one of the newsgroups a few years ago) is that detecting modifiers doesn't work if you try using one of the pairs of keys such as Alt_L as a meta key. (I don't recall the explanation, other than that it was a limitation of the way the modifier information is stored). I just setup a case like that, and indeed it doesn't work. For instance, using this with xmodmap: keycode 115 = Meta_L add mod1 = Meta_L remove mod1 = Alt_L produces this output from xmodmap (but I'm puzzled by the stray , which looks as if I have more work to do): xmodmap: up to 3 keys per modifier, (keycodes in parentheses): shift Shift_L (0x32), Shift_R (0x3e) lockCaps_Lock (0x42) control Control_L (0x25), Control_R (0x6d) mod1 , Alt_R (0x71), Meta_L (0x73) mod2Num_Lock (0x4d) mod3 mod4Meta_L (0x73), Super_R (0x74) mod5 and in xterm's trace I have VTInitModifiers alt_right mask 0x8 is Mod1 modifier meta_left mask 0x8 is Mod1 modifier num_lock mask 0x10 is Mod2 modifier meta_left mask 0x48 is Mod1 modifier TranslationsUseKeyword(0x80c10f0):#override so that might be roughly what you have. Checking the rest of Trace-parent.out, I don't see any modifiers when I press left-alt (meta). The lines beginning Input keysym would show any modifiers that are in the event. In the text below, I pressed left-alt + 'm' twice (no mod1), but pressing right-alt with 'm' got a modifier. Input keysym 0xFFE9, 0:'' 7bit Input keysym 0x006D, 1:'m' 7bit Input keysym 0x006D, 1:'m' 7bit Input keysym 0xFFEA, 0:'' 7bit Input keysym 0x006D, 1:'m' 7bit Input keysym 0x006D, 1:'m' 7bit Input keysym 0xFFE4, 0:'' 7bit Input keysym 0x006D, 1:'^M' Control 7bit Input keysym 0x006D, 1:'^M' Control 7bit Input keysym 0xFFE7, 0:'' 7bit Input keysym 0x006D, 1:'m' Mod1 Mod4 8bit Input keysym 0x006D, 1:'m' Mod1 Mod4 8bit Input keysym 0xFFE3, 0:'' 7bit Input keysym 0x0064, 1:'^D' Control 7bit Input keysym 0x0064, 1:'^D' Control 7bit gnome-terminal might be trapping the keypress events (something to check on), or getting the information in some other way that hasn't occurred to me. -- Thomas E. Dickey http://invisible-island.net ftp://invisible-island.net pgpV0bSYfwhFB.pgp Description: PGP signature
Bug#260232: xterm: XTerm*metaSendsEscape no longer working
Backing up a little, I did this: keycode 0x40 = Meta_L Alt_L and got xmodmap's output a little saner: xmodmap: up to 2 keys per modifier, (keycodes in parentheses): shift Shift_L (0x32), Shift_R (0x3e) lockCaps_Lock (0x42) control Control_L (0x25), Control_R (0x6d) mod1Meta_L (0x40), Alt_R (0x71) mod2Num_Lock (0x4d) mod3 mod4Super_L (0x73), Super_R (0x74) mod5 and my resulting trace is working fine: VTInitModifiers meta_left mask 0x8 is Mod1 modifier alt_right mask 0x8 is Mod1 modifier num_lock mask 0x10 is Mod2 modifier TranslationsUseKeyword(0x80a9ea8):#override and (using left-alt as meta): Handle 8bit-key Input keysym 0x006D, 1:'m' Mod1 8bit ...input-char is modified by META I also see right-alt interpreted as meta since they have the same modifier. That could be surprising if one isn't reading the debug trace. I don't use xmodmap often, so it does take some practice and experimentation. On my keyboard, I don't see a Meta_L or Meta_R by default, so adding it does require xmodmap. -- Thomas E. Dickey http://invisible-island.net ftp://invisible-island.net pgpeNhgMhNscU.pgp Description: PGP signature
Bug#260232: xterm: XTerm*metaSendsEscape no longer working
Package: xterm Version: 4.3.0.dfsg.1-6 Severity: normal Hi, the above is no longer working after an upgrade to the versions below. Before that I could use: Alt-f, Alt-b to jump whole words forward or backward in a bash running within xterm. This doesn't work anymore, ESC-f, ESC-b still works though. Any ideas where to start digging? Cheers, -- Guido P.S.: I'm additionally using: keysym Alt_L = Meta_L Alt_L to make the above work. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: powerpc (ppc) Kernel: Linux 2.6.8-rc2-albook12 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 Versions of packages xterm depends on: hi libc6 2.3.2.ds1-13 GNU C Library: Shared libraries an ii libexpat1 1.95.6-8 XML parsing C library - runtime li ii libfontconfig12.2.3-1generic font configuration library ii libfreetype6 2.1.7-2.1 FreeType 2 font engine, shared lib ii libice6 4.3.0.dfsg.1-6 Inter-Client Exchange library ii libncurses5 5.4-4 Shared libraries for terminal hand ii libsm64.3.0.dfsg.1-6 X Window System Session Management ii libxaw7 4.3.0.dfsg.1-6 X Athena widget set library ii libxext6 4.3.0.dfsg.1-6 X Window System miscellaneous exte ii libxft2 2.1.2-6FreeType-based font drawing librar ii libxmu6 4.3.0.dfsg.1-6 X Window System miscellaneous util ii libxpm4 4.3.0.dfsg.1-6 X pixmap library ii libxrender1 0.8.3-7X Rendering Extension client libra ii libxt64.3.0.dfsg.1-6 X Toolkit Intrinsics ii xlibs 4.3.0.dfsg.1-6 X Window System client libraries m ii xlibs-data4.3.0.dfsg.1-6 X Window System client data -- no debconf information
Bug#260232: xterm: XTerm*metaSendsEscape no longer working
On Mon, Jul 19, 2004 at 04:30:13PM +0200, Guido Guenther wrote: Package: xterm Version: 4.3.0.dfsg.1-6 Severity: normal Hi, the above is no longer working after an upgrade to the versions below. Before that I could use: Alt-f, Alt-b to jump whole words forward or backward in a bash running within xterm. This doesn't work anymore, ESC-f, ESC-b still works though. Any ideas where to start digging? man xterm metaSendsEscape -- Thomas E. Dickey http://invisible-island.net ftp://invisible-island.net pgpJaacCK3xll.pgp Description: PGP signature
Bug#260232: xterm: XTerm*metaSendsEscape no longer working
On Mon, Jul 19, 2004 at 04:30:13PM +0200, Guido Guenther wrote: Package: xterm Version: 4.3.0.dfsg.1-6 Severity: normal Hi, the above is no longer working after an upgrade to the versions below. Before that I could use: Alt-f, Alt-b to jump whole words forward or backward in a bash running within xterm. This doesn't work anymore, ESC-f, ESC-b still works though. Any ideas where to start digging? I don't think the problem is within xterm (it's been a while since I tweaked the logic for this). More likely something in the keyboard configuration has separated the definitions that you were relying upon. What I do to debug this is to use xev and ensure that it's reporting Meta_L for the key. If that's right, I generally compile a debug version of xterm (configure --enable-trace) and check the initialization of the modifiers. I did check over this recently and recall that there was some issue where one could accidentally setup a conflict that would make xterm not do meta. But that also showed up in xmodmap's display. -- Thomas E. Dickey http://invisible-island.net ftp://invisible-island.net pgpOeBDUY2d07.pgp Description: PGP signature
