Solving the modifiers issue with emacs and XFree86 4.3
Hi,
as explained in #255286, bug submitter has problems with his
configuration, logo keys are bound to Meta, but emacs believes that they
are bound to Meta+Super+Hyper, and of course shortcuts do not work as
expected.
The root of the problem is that XFree86 4.3 (in fact future versions,
but patches were backported by XFree86 Debian maintainers) introduced
the so called 'fake keys' which do not correspond to any real key, but
are internally used by XKB to trigger specific events. This was meant
to solve problems with multiple layouts (like us,ru) when modifiers are
bound to different keys for each national layout.
So people claim that this is an XFree86 issue. But Debian packages
won't get fixed, otherwise the problems described above will reappear.
There is another solution, I supplied a patch to #255286, which is
really safe, which means that a working configuration cannot break,
most broken configurations will be fixed (I checked with all altwin:*
options), and few broken configurations will still get broken (the
latter is just for completeness, I did not try to find examples).
Moreover this patch is very small, so it can easily be reviewed.
What is this patch about?
This is pretty simple, the x_find_modifier_meanings function in
src/xterm.c scan all keycodes bound to mod[1-5], get all their
KeySyms, and look for XK_{Alt,Meta,Super,Hyper}_{L,R} Keysyms.
A bit mask is set, and (in short) due to altwin:meta_win XKB option:
alt_mod_mask = mod1
meta_mod_mask = mod1 | mod4
super_mod_mask = hyper_mod_mask = mod4
When emacs receives a KeyPress/KeyRelease with mod4 set, it activates
Meta+Hyper+Super modifiers.
But whenever different KeySyms are bound to the same modifier mod[1-5],
emacs is confused and unable to process these shortcuts. So instead of
collecting all KeySyms, a smarter way is to stop scanning KeySyms when
one is found. There is a special treatment for Alt+Meta in original
source code, so I had to handle this specific case too in order to be
compatible with the current behavior.
Unfortunately I was unable to build emacs21 on my old slow computer, and
isolated this function to display the mentioned bit masks when this patch
is applied, so I am pretty sure that it works fine.
Please consider applying this patch to emacs21, I see no other way to
solve this annoying bug for sarge.
If xemacs21 maintainer is willing to solve this issue as well, let me
know and I will have a look, but sources are very different.
At the moment, only altwin:super_win and altwin:hyper_win options can be
tested, there is a bug in xlibs which prevents altwin:meta_win to work
correctly, but it will be fixed by a coming soon upload.
Denis
Reply to: