Re: xmodmap, readline, and ye olde meta key
Re: xmodmap, readline, and ye olde meta key
- Subject: Re: xmodmap, readline, and ye olde meta key
- From: "James K. Lowden" <email@hidden>
- Date: Sat, 8 Jan 2011 18:55:33 -0500
Hi Jeremy,
Thank you for your detailed reply. I read the discussion my post
generated with great interest. It was very helpful. It took so long to
reply because you gave me a lot of homework and I'm a slow student,
especially during the holidays.
> > 1. move-by-word to work by pressing alt-f and alt-b
>
> That's not really an X11 issue. That's a bash issue. You should
> create/edit /etc/inputrc or ~/.inputrc
I now know I cannot solve this with .inputrc alone. Why? Because neither
command-b nor option-b emit anything! Only command-option-b does.
Part of my confusion stems from the many layers of software a keystroke
passes through on its way to the application, bash in this case. I think
it looks something like this:
0. hardware generates an interrupt
1. a kernel device generates a keycode
2. X generates a keysym
3. xterm generates an escape sequence, such that the left-arrow key
becomes 1b 4f 44
4. application receives 1b 4f 44
That's my mental framework. Question #1 is, what does bash see?
With an xterm open running bash, if I type the following,
$ hexdump
1
control-v control-b
2
control-v option-b
3
control-v command-b
4
control-v option-command-b
5
control-d
return
control-d
this is what I see:
$ hexdump # xterm
1^B234รถ5^D
0000000 31 02 32 33 34 f6 35 0a
0000008
which I interpret as:
0000000 31 02 32 33 34 f6 35 0a
1 ^B 2 3 4 | 5 return
+- output of command-option-b
For reasons I don't understand, 0xf6 *does* cause bash (i.e. readline) to
move back by word. What is clear is that neither option-b nor command-b
generate anything. That is true irrespective of "Enable key equivalents"
in X11 input preferences.
Repeating the experiment with the OS X Terminal (where I find no
move-by-word functionality) I see:
$ hexdump # Terminal
1^B2?345^D
0000000 31 02 32 e2 88 ab 33 34 35 0a
000000a
which I interpret as:
0000000 31 02 32 e2 88 ab 33 34 35 0a
1 ^B 2 3 4 5 return
I don't know what e2 88 ab (from option-b) are, but in Terminal it looks
like a small integral symbol from calculus (U+8757?). Maybe this isn't
too surprising; it seems to be what X would show, too, if it had that
glyph:
$ xmodmap -pke | grep integral
keycode 19 = b B integral idotless
In any case it would seem that if I could (somehow) define e2 88 ab in
.inputrc I would have move-by-word in Terminal (but not where it matters,
in xterm). But that's not an X11 issue. :-)
Finally, X11 sends keysyms to xterm. What does it send for option-b?
KeyPress event, serial 26, synthetic NO, window 0xc00001,
root 0x67d, subw 0x0, time 1744669534, (151,-17), root:(175,25),
state 0x0, keycode 63 (keysym 0xffe7, Meta_L), same_screen YES,
XLookupString gives 0 bytes:
XmbLookupString gives 0 bytes:
XFilterEvent returns: False
KeyPress event, serial 29, synthetic NO, window 0xc00001,
root 0x67d, subw 0x0, time 1744671463, (151,-17), root:(175,25),
state 0x10, keycode 19 (keysym 0x62, b), same_screen YES,
XLookupString gives 1 bytes: (62) "b"
XmbLookupString gives 1 bytes: (62) "b"
XFilterEvent returns: False
KeyRelease event, serial 29, synthetic NO, window 0xc00001,
root 0x67d, subw 0x0, time 1744671686, (151,-17), root:(175,25),
state 0x10, keycode 19 (keysym 0x62, b), same_screen YES,
XLookupString gives 1 bytes: (62) "b"
XFilterEvent returns: False
KeyRelease event, serial 29, synthetic NO, window 0xc00001,
root 0x67d, subw 0x0, time 1744672646, (151,-17), root:(175,25),
state 0x10, keycode 63 (keysym 0xffe7, Meta_L), same_screen YES,
XLookupString gives 0 bytes:
XFilterEvent returns: False
I don't know how to interpret this. I include it because you do!
Conclusions:
1. xterm generates 0xf6 for command-option-b, and nothing for either
alone.
2. X11 interprets comamnd-b as "b", cf. XLookupString above. Presumably
it ignores it because "b" with state 0x10 has no meaning (why?) on my
machine.
3. X11 preferences have no effect on these keystrokes.
This for sure: I can't map nothing to something. How do I encourage my
10.6.5 system to emit something for bash to interpret?
Maybe it's my fault somehow? In case it's relevant, xmodmap reports:
$ xmodmap -p
xmodmap: up to 2 keys per modifier, (keycodes in parentheses):
shift Shift_L (0x40), Shift_R (0x44)
lock Caps_Lock (0x41)
control Control_L (0x43), Control_R (0x46)
mod1 Meta_L (0x42), Mode_switch (0x45)
mod2 Meta_L (0x3f), Meta_R (0x47)
mod3
mod4
mod5
$ xmodmap -pke | grep _[LR]
keycode 63 = Meta_L
keycode 64 = Shift_L
keycode 65 = Caps_Lock
keycode 66 = Meta_L
keycode 67 = Control_L
keycode 68 = Shift_R
keycode 70 = Control_R
keycode 71 = Meta_R
Just couple more general questions and observations, if I may:
> I assume you mean X(7) .
Yes, sorry.
>> I find no
>> reliable information on whether or no ${HOME}/.xinitrc is supposed to
>> work.
> As with all recent distributions, ~/.xinitrc is deprecated in favor of >
> ~/.xinitrc.d, but it will work ... chances are your ~/.xinitrc as why
> xmodmap wasn't being run.
I think the Internet dropped a word or two on you? ;-)
Thanks. I wasn't aware of xinitrc.d. My xinit(1) man page doesn't
mention it.
One last question: can you recommend an X11 book? I learned C from K&R,
C++ from Stroustrup, Unix IPC from Stevens, and SQL from Date. I don't
want to program X, but I find it hard to understand all the knobs. I did
find http://www.sbin.org/doc/Xlib/chapt_09.html helpful.
Regards,
--jkl
_______________________________________________
Do not post admin requests to the list. They will be ignored.
X11-users mailing list (email@hidden)
This email sent to email@hidden