>>>> "Krishnakumar" == Krishnakumar B
<Krishnakumar> writes:
Krishnakumar> Maybe XEmacs is using some deprecated xkb extension
Krishnakumar> which got nuked with XFree86 4.3.x.
Nope, I got it figured out. (I think; it'll take a while to generate
a proof in the form of a patch, because I know that (5) below happens,
but not where in the code.)
1. XEmacs gets an event for the chord Sh-F1
2. The event contains the keysym 0x1008fe01 (as an integer)
3. XEmacs attempts to look it up to get a string representation to
intern, but it is linked against a different version of Xlib from
the server (see src/event-Xt.c, l. 907), so XKeysymToString gives
NULL instead of returning XF86_Switch_VT_1 as xmodmap does[1]
4. So XEmacs turns back to the event and extracts the actual keycode
5. Which it buggily translates to F1, because the guy who figured out
all of the above forget to check the modifier state vector for "shift"
What this means is simple: I guess that as soon as SuSE (or you)
rebuilds everything with consistent libs and headers, XEmacs (and GNU
Emacs, I bet) will signal an error "unknown keysym: XF86_Switch_VT_1"
instead of returning F1 (XEmacs) or Sh-F1 (GNU).
So XEmacs is buggy, but xmodmap _is_ the right solution. (Well, maybe
sending a nastygram to XFree86 is in order. Maybe....)
Of course, there is another possibility that I was not even counting
upon: XF86_Switch_VT_1 is a new private keysym that only the server
and Xmodmap know about....
Footnotes:
[1] Yes, I can see this is somewhat bogus, but the lookup _is_
failing, and not just for XEmacs. If you want a better explanation,
look in the XFree86 sources.
--
Institute of Policy and Planning Sciences
http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
You can get anything you want / At Alice's Restaurant.