Re: problem with shifted function keys on FC3 X11
Thank you Stephen, that sounds a lot worse than I'd hoped (I really
wish I had the time to hack on XEmacs again but it's going to be at
least a few more years). For a while I just xmodmapped away those
extra keysyms, but then I lost the ability to switch virtual terminals
(Control-Alt-F<n>). So I guess I'll just have to move those bindings
elsewhere for now.
Hope you all are doing well,
greg
>>>> Stephen J Turnbull <stephen(a)xemacs.org> writes:
>>>> "Greg" == Greg Klanderman
<gak+xemacs(a)klanderman.net> writes:
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
I looked).
Patches welcome!