Bug#350298: Anyone working on this?
The problem is still there in unstable. I can't update x11-common from 6.8.2-dfsg.1-11 to 6.9-dfsg.1-4 because of this bug. Is anyone working on this? Thanks, Felix -- | Felix Kühling <[EMAIL PROTECTED]> http://fxk.de.vu | | PGP Fingerprint: 6A3C 9566 5B30 DDED 73C3 B152 151C 5CC1 D888 E595 |
Bug#350298: Any updates or progress?
Hi, I haven't heard back on this bug report in two weeks and the problem persists. Is anyone going to look into this? If there is anything I can do to help, please let me know. Thanks and regards, Felix -- | Felix Kühling <[EMAIL PROTECTED]> http://fxk.de.vu | | PGP Fingerprint: 6A3C 9566 5B30 DDED 73C3 B152 151C 5CC1 D888 E595 |
Bug#241034: xlibs: Meta key not working in emacs with XkbOptions altwin:left_meta_win
On Sat, 17 Apr 2004 00:50:58 +0200 [EMAIL PROTECTED] (Denis Barbier) wrote: > On Wed, Mar 31, 2004 at 01:02:43PM +0200, Felix Kühling wrote: > [...] > > If this is a bug in Emacs then I wonder why the Meta-key works correctly > > with altwin:meta_win but fails with altwin:left_meta_win. How is the > > left Windows key handled differently between the two options? Should > > there be any difference? If not then I'd suspect that it's rather a > > problem in X. > > Erwan David explained (in French) in this thread > http://lists.debian.org/debian-user-french-0404/msg00412.html > and in #234081 that with altwin:left_meta_win, Mod4 is bound to Meta_L > and Super_R. But (X)emacs seems not to be XKB-aware, and thus it cannot > determine whether Meta_L or Super_R is pressed when it received a Mod4 > event, and Mod4 is disabled. > > If (X)emacs used XKB extensions, it could make this distinction, so one > could argue that this is a limitation in (X)emacs. > > But on the other hand, having 2 keys of distinct types (Meta and Super) > bound to the same modifier is certainly not a good idea; if these keys > handle different actions, binding them to different modifiers is > natural. This is what Erwan does in #234081 to fix this problem. > I filed http://bugzilla.xfree86.org/show_bug.cgi?id=1344 but I am afraid > that mapping a key to another modifier might cause other trouble, so > let's see what upstream will propose. Thanks for the explanation. If I understand you correctly then from the XFree86 point of view this bug is probably a duplicate of #234081. > > It seems that people use altwin:left_meta_win mostly because > altwin:meta_win cancels AltGr, see > http://bugzilla.xfree86.org/show_bug.cgi?id=1341 Right, that was the reason why I went with left_meta_win. > But this one can easily be fixed, here is a patch. All *_win options > are then handled in a similar manner and do not modify Alt keys. Thanks a lot! I applied your patch in /etc/X11/xkb and am happily using altwin:meta_win now. > > Denis > Felix
Bug#241034: xlibs: Meta key not working in emacs with XkbOptions altwin:left_meta_win
On Tue, 30 Mar 2004 21:59:44 +0200 [EMAIL PROTECTED] (Denis Barbier) wrote: > On Tue, Mar 30, 2004 at 02:51:22PM +0200, Felix Kuehling wrote: > > Package: xlibs > > Version: 4.3.0-7 > > Severity: normal > > > > The meta key stopped working after upgrading to XFree86 4.3. This is with > > XkbOptions set to "altwin:left_meta_win, compose:menu". It used to work with > > XFree86 4.2.x. The left windows-key was Meta. > [...] > > I made some experiments with xev, once with > > altwin:left_meta_win,compose:menu, > > once without it. It's funny that Alt_L+X produces the same result in both > > cases, but with the XkbOptions emacs doesn't recognize Alt_L+X. :-/ > > Are these keys working right in xterm? If yes, this is most likely an > emacs problem, it looks similar to > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=165814&msg=7 Hmm. It does work in xterm. In gnome-terminal I have to use Alt_L as Meta-key though. If this is a bug in Emacs then I wonder why the Meta-key works correctly with altwin:meta_win but fails with altwin:left_meta_win. How is the left Windows key handled differently between the two options? Should there be any difference? If not then I'd suspect that it's rather a problem in X. And it's not a problem with the Xserver itself, because the problem also occurs with a self-built server from the DRI project that I was using before the XFree86 upgrade without problems. > > Denis Felix
