>>>> "Greg" == Greg Klanderman
Greg> Since switching to Fedora Core 3 from Red Hat 7.3, shifted
Greg> versions of the function keys and some keypad keys are no
Greg> longer distinguished from their non-shifted counterparts.
Greg> on FC3, there are two:
| % xmodmap -pk | grep -i kp_multiply
| 63 0xffaa (KP_Multiply) 0x1008fe21 (XF86_ClearGrab)
This looks like more of that evil "we've got XKB, we don't need no
steenkin' backward compatibility" stuff. What is happening is that
there is no shifted keysym, but XKB makes it look like there is one.
Ony XKB can tell the difference; legacy X keyboard handlers cannot.
Greg> Or XLookupKeysym is just broken, and we need to instead call
Greg> XLookupString once on the event we received, and again on a
Greg> copy of that event with the shift bit cleared, and compare
Greg> those keysyms.
Sorry, that's unibyte-specific. At last report, it breaks Asian input
methods on both Solaris and HP/UX (although it may work on Linux).
The compose characters get cleared.
Greg> However, it would be nice to solve the problem in XEmacs. I
Greg> didn't look at their code, but FSFMacs is not exhibiting
Greg> this problem.
Their keyboard code is very different. I'm afraid we need to rip out
all of our keyboard code and replace it with XKB-compatible stuff (or
more likely, keep the old stuff for backward compatibility).
Unfortunately, that's non-trivial and XKB is undocumented (again, last
School of Systems and Information Engineering http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
Ask not how you can "do" free software business;
ask what your business can "do for" free software.