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: > > ~Meta<KeyPress>: 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
