[Konsole-devel] Bug#40751: meta keys no longer get through to bash

[Benjamin S. Scarlet]

On Thursday 11 April 2002 04:24 pm, Stephan Binner wrote:
> > meta-<foo> no longer gets through to bash.
>
> What is meta? Win? Alt? Solaris' Meta?

Oops. Sorry to be so vague.
Short answer, meta is the X keysym.

Long answer:
The text on the plastic is "Alt". 

running xmodmap to reveal my modifiers, I get:
xmodmap:  up to 2 keys per modifier, (keycodes in parentheses):

shift       Shift_L (0x32),  Shift_R (0x3e)
lock        Caps_Lock (0x75)
control     Control_L (0x42)
mod1        Meta_L (0x40)
mod2        Num_Lock (0x4d)
mod3        Alt_L (0x25)
mod4        Hyper_L (0x74),  Hyper_R (0x6d)
mod5        Super_R (0x71),  Super_L (0x73)

and pressing the key in question while running xev produces:

KeyPress event, serial 28, synthetic NO, window 0x1a00001,
    root 0x32, subw 0x0, time 653167439, (9,155), root:(1369,564),
    state 0x0, keycode 64 (keysym 0xffe7, Meta_L), same_screen YES,
    XLookupString gives 0 characters:  ""

> > For instance (with bash configured to use emacs sequences so meta-b means
> > go backward a word), typing "bar" followed by meta-b jumps backward over
>
> Alt-b goes one word back here (like Alt Left). Win-b prints "b" character.

Interesting. Pressing my "Alt" (mod3) key _does_ work -- but that's not what I 
think should happen. Most linux setups default to binding the Alt keysym to 
the key labelled "alt," and then let unix programs interpret Alt to mean 
Meta.  I've rearranged my keys to go the old fashioned Unix way, with an 
actual "meta" keysym.  I think the "<foo>-b goes backwards" behaviour should 
have stayed with either the <foo> which is defined as X mod1, or with the 
<foo> which is _any_ X modifier key and has a keysym named Meta_L or Meta_R. 
I do _not_ think the behaviour should have moved to stay with the key with 
the name "alt.", at least not without some way of changing it. Is there such?

	Thanks,
	 Benjamin S. Scarlet