Uwe Brauer wrote:
>>>>> "Stephen" == Stephen J Turnbull
<stephen(a)xemacs.org> writes:
Bad explained sorry, what I meant is the following:
I use my .Xmodmap to map the print and the break key to
F13 and F15, using
keycode 0x6F = F13 Sys_Req
keycode 0x6E = F15 Break
If I do that I can bind `F13', control and meta `F13', but not
shift `F13', so the situation seems different.
But that looks very similar. Did you try to leave off Sys_Req and Break from
your keycode definition? Does XEmacs detect Sh-F13 then?
Somewhere the code has to decide if it shall associate a modifier or not (from a
first glance, that might be the loop at the end of x_reset_key_mapping() in
event-Xt.c). And here something seems to go wrong.
- I find it curious that Joachim reported that problem for
that xemacs version, but for other version the shift key
behaves fine, while I suffer that problem even in xemacs
21.4.17 no mule
For reference, my current test environment are two boxes: One with SUSE 9.2 and
XEmacs 21.4 Mule (from SUSE) and one with SUSE 10.0 and XEmacs 21.5 (corn from
SUSE and daikon self-compiled). (I'm midst in the process of migrating.) The
SUSE versions don't have that problem, the self-compiled version has it. The
behavior is independent of the X server version.
As Stephen wrote, probably it's best to look at xemacs-patches and/or the
changes in the SUSE source to see if and what Mike Fabian has changed in event-Xt.c.
Cheers,
Joachim
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Joachim Schrod Email: jschrod(a)acm.org
Roedermark, Germany