Bug 40751

> meta-<foo> no longer gets through to bash.

What is meta? Win? Alt? Solaris' Meta?

> 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.

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".=20

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 (9155) root:(1369564)
    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 mea=
ns
> > 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 wha=
t I=20
think should happen. Most linux setups default to binding the Alt keysym to=
=20
the key labelled "alt" and then let unix programs interpret Alt to mean=20
Meta.  I've rearranged my keys to go the old fashioned Unix way with an=20
actual "meta" keysym.  I think the "<foo>-b goes backwards" behaviour shoul=
d=20
have stayed with either the <foo> which is defined as X mod1 or with the=
=20
<foo> which is _any_ X modifier key and has a keysym named Meta_L or Meta_R=
.=20
I do _not_ think the behaviour should have moved to stay with the key with=
=20
the name "alt." at least not without some way of changing it. Is there suc=
h?

Thanks
 Benjamin S. Scarlet

I'm using a Kinesis keyboard (Essential, no support for remapping keys), and using xmodmap 
to arrange my keys in a convenient manner.  With such a keyboard, some keys are different
(e.g., keys with keycode 115-117 are only available when a special "Keypad" toggle is active,
and they are then located on "H", "N", and "<quote>").  For anybody with an unusual keyboard
or anybody who is using xmodmap to rearrange their keys, it is important to be able to control
the effect of keys using their X keysym/modifier settings, rather than relying on the hardwired
keycode values.

Is it correct that konsole will now insist on using the physical "Alt" (left?) key in order to 
type <meta-b> and achieve a "word backward" effect (and a lot of similar commands with 
<meta-X> for other values of X) with zsh, bash and similar programs?  I tried to test this 
hypothesis (see below), but I haven't been able to confirm it.

When I updated to a new version of konsole (it says "Qt: 3.0.5, KDE: 3.0.5, Konsole: 
1.1.3"), all the <meta-foo> editing commands suddenly stopped working.  I use Meta (which is 
keycode 107, keysym Meta_L, modifier mod1) to achieve the "word backward" effect  with "b"
in Emacs and (until recently) in konsole+zsh.

This seems to be impossible today (I can't find a modifier that lets keycode 107, modifier 
Meta_L have the desired effect), but I cannot make the physical Alt keys work either.

I tried out all the following combinations:

  Keycode Keysym Modifier
  64            Alt_L      mod1
  64            Alt_R      mod1
  64            Alt_L      mod3
  64            Alt_R      mod3
  113          Alt_L      mod1
  113          Alt_R      mod1
  113          Alt_L       mod3
  113          Alt_R       mod3

I tried to press the specified "Alt" key and "B" with each of the above settings, and in none 
of the cases did the "word backward" command execute, the command line was just 
extended with a "b".

So in what sense does "Alt" have the <meta-..> effect?  I don't seem to be able to make 
that happen.  And even then, I'd much prefer to have these editing commands on the 
Meta_L/mod1 key, such that it works like in Emacs.

Hoping that I can soon get back my missing editing commands on the command line ..  :-)

    Thanks -
    Erik Ernst

The problem can be fixed in the following way (based on the source rpm
file 'kdebase3-3.0.4-6.src.rpm').  Note that this is a 'quice-n-dirty'
solution (I don't even know how many conventions I'm breaking), but it's
easy, and it solves the problem for me .. It is now again possible for
me to use meta-B and friends for command line editing.  :-)

Here are the tiny patches:

--------------------------------------------------------------------------
Patch for keytrans.h
--------------------------------------------------------------------------
27c27,28
< #define BITS_COUNT      7
---
> #define BITS_Meta       7
> #define BITS_COUNT      8
--------------------------------------------------------------------------
Patch for TEmuVt102.cpp
--------------------------------------------------------------------------
824c824,825
<                                      encodeStat(AltButton     , BITS_Alt  
     ),
---
>                                      encodeStat(AltButton     , BITS_Alt  
     ) +
>                                      encodeStat(MetaButton    , BITS_Meta 
     ),
872c873
<     if ((ev->state() & AltButton) && !metaspecified ) sendString("\033");
---
>     if ((ev->state() & MetaButton) && !metaspecified ) sendString("\033");
880c881
<     if (ev->state() & AltButton) sendString("\033"); // ESC, this is the 
ALT prefix
---
>     if (ev->state() & MetaButton) sendString("\033"); // ESC, this is the 
ALT prefix
--------------------------------------------------------------------------

HTH, Erik Ernst

In the patches given in the previous comment, some newlines have
somehow been added by the uploading software.  Hence, to get the
correct patch you must first remove the newline in 5 places:  After
the word 'BITS_Alt', 'BITS_Alt', 'BITS_Meta', 'the', and 'the'.
Moreover, white space was compressed to single spaces.  However,
you can easily reconstruct the correct spacing if you insert the
changes manually---it's only adding 2 lines and changing 3 lines,
after all.

HTHF (Hope This Helps, Finally :-),
  Erik Ernst

Replaced kde-bug-receive@greynode.net with eernst@daimi.au.dk due to bounces by reporter

The problem apparently has been solved in newer versions of the software (I'm running SuSE 9.1 now, and 'konsole --version' yields: Qt: 3.3.1, KDE: 3.2.1, Konsole: 1.3.1).

(Marking this bug as resolved).