From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Alex Viskovatoff Newsgroups: gmane.emacs.help Subject: Making Windows key meta Date: Wed, 09 Jun 2004 12:18:41 -0400 Sender: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Message-ID: NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 8bit X-Trace: sea.gmane.org 1088535152 15998 80.91.224.253 (29 Jun 2004 18:52:32 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Tue, 29 Jun 2004 18:52:32 +0000 (UTC) Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Tue Jun 29 20:52:25 2004 Return-path: Original-Received: from lists.gnu.org ([199.232.76.165]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1BfNiS-0002uy-00 for ; Tue, 29 Jun 2004 20:52:24 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1BfNk8-0000op-62 for geh-help-gnu-emacs@m.gmane.org; Tue, 29 Jun 2004 14:54:08 -0400 User-Agent: Pan/0.14.2 (This is not a psychotic episode. It's a cleansing moment of clarity.) Original-Newsgroups: gnu.emacs.help Original-NNTP-Posting-Host: dialup-44-252-186-140.computer.net Original-X-Trace: newsfeed.slurp.net 1086797941 140.186.252.44 (9 Jun 2004 11:19:01 -0500) Original-Lines: 60 X-Original-NNTP-Posting-Host: 140.186.252.44 Original-Path: shelby.stanford.edu!newsfeed.stanford.edu!logbridge.uoregon.edu!feed1.news.rcn.net!rcn!in.100proofnews.com!in.100proofnews.com!newsfeed.slurp.net!not-for-mail Original-Xref: shelby.stanford.edu gnu.emacs.help:123713 Original-To: help-gnu-emacs@gnu.org X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: Users list for the GNU Emacs text editor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Xref: main.gmane.org gmane.emacs.help:19080 X-Report-Spam: http://spam.gmane.org/gmane.emacs.help:19080 Hi, This issue has come up many times before on discussion groups, but the specific problem I run into has not, as far as I am aware. Because the laptop I use has a narrow space bar, it is inconvenient for me to use the alt keys for meta, since the alt keys are awkwardly far away from the control keys. I am running xorg-x11 6.7 (equivalent to XFree86 4.4) under Fedora Core 2 with Gnome 2.6, and that allows me to modify the xkb options in my user settings. In the Gnome "Keyboard Preferences" configuration, I select "Meta is mapped to the Win-keys", which makes the options "altwin altwin:meta_win" sent to xkb. In an xterm, this makes the Windows key act as meta. With this configuration, xev shows that pressing the left Windows key yields "keycode 115 (keysym 0xffe7, Meta_L)", while pressing the left alt key yields "keycode 64 (keysym 0xffe9, Alt_L)". This is what I expect, and what I want. In the previous version of Emacs I used, this configuration also made the Windows key act as meta under Emacs. Now however, under this configuration, pressing both the (left) Windows key or the alt key doesn't do anything. (If I don't give the "altwin altwin:meta_win" option to xkb, Emacs treats the alt key as meta.) Using "C-h k" shows what the problem is. What it yields for "win-b" (pressing "b" while holding the Windows key down) is "H-M-s-b is undefined". In other words, when one presses the Windows key, in Emacs, not only the meta bit gets set, but also the hyper and super bits. On the other hand, if I don't give the "altwin altwin:meta_win" option to xkb, pressing "b" with the Windows key down in Emacs makes "C-h k" yield "H-S-b is undefined". Under this configuration, xev reports the Windows key as "keycode 115 (keysym 0xffeb, Super_L)", while it continues to report the left alt key as "keycode 64 (keysym 0xffe9, Alt_L)". Again, X is behaving exactly as expected, since the default behavior for X is that the Windows key is super. So what Emacs does is the following. When the Windows key is mapped to super (the default), Emacs treats it as "H-s". When the Windows key is mapped to meta, emacs treats it as "H-M-s". So Emacs is aware of the Windows key being remapped under X. But why, when the Windows key is mapped to meta under X, does Emacs set the hyper and super bits, while not just setting the meta bit, which would be the expected, "reasonable" behavior? A workaround would be to associate, for instance, the "backward-word" command with the "H-M-s-b" keystroke, instead of "M-b". But that would be highly kludgey, as well as breaking emacs when it is not run under X. I thought that this strange behavior might be caused by one of Red Hat's patches to Emacs, so I compiled the emacs 21.3 myself. The behavior is exactly the same. Does anyone know why Emacs behaves in this bizarre way? (As far as I can tell, the entry "After upgrading to a newer version of Emacs, the Meta key stops working" in the emacs "PROBLEMS" file does not lead one to expect this behavior.) And does anyone know a reasonably easy way to make Emacs behave in a straightforward way, that is, to interpret keyboard events from X with the Windows key down as just having the meta bit set, as opposed to having the hyper, meta, and super bits set? Any clarification will be much appreciated.