From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Drew Adams" Newsgroups: gmane.emacs.devel Subject: RE: question about Meta + Shift modifiers: M-S-r and M-R Date: Sat, 26 Jan 2013 08:24:40 -0800 Message-ID: References: <5C78448DD5B849F9A64C2489478EC4D9@us.oracle.com> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1359217501 6232 80.91.229.3 (26 Jan 2013 16:25:01 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 26 Jan 2013 16:25:01 +0000 (UTC) Cc: emacs-devel@gnu.org To: "'Andreas Schwab'" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Jan 26 17:25:20 2013 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Tz8ZB-0008Gk-8o for ged-emacs-devel@m.gmane.org; Sat, 26 Jan 2013 17:25:17 +0100 Original-Received: from localhost ([::1]:54618 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Tz8Yt-0007lK-Lb for ged-emacs-devel@m.gmane.org; Sat, 26 Jan 2013 11:24:59 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:38412) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Tz8Yp-0007l3-GX for emacs-devel@gnu.org; Sat, 26 Jan 2013 11:24:57 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Tz8Yk-0002RU-Gt for emacs-devel@gnu.org; Sat, 26 Jan 2013 11:24:55 -0500 Original-Received: from userp1040.oracle.com ([156.151.31.81]:41671) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Tz8Yk-0002RL-A9 for emacs-devel@gnu.org; Sat, 26 Jan 2013 11:24:50 -0500 Original-Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by userp1040.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id r0QGOmk2015546 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 26 Jan 2013 16:24:49 GMT Original-Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r0QGOlr5002598 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 26 Jan 2013 16:24:48 GMT Original-Received: from abhmt111.oracle.com (abhmt111.oracle.com [141.146.116.63]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id r0QGOl8L027883; Sat, 26 Jan 2013 10:24:47 -0600 Original-Received: from dradamslap1 (/71.202.147.44) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sat, 26 Jan 2013 08:24:47 -0800 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: Thread-Index: Ac37sDZzCcbpsSJ0STqC+tTJCs/HIwALHZ8A X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-Source-IP: acsinet22.oracle.com [141.146.126.238] X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.4.x-2.6.x [generic] X-Received-From: 156.151.31.81 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:156655 Archived-At: > This has nothing to do with Meta. It has _something_ to do with Meta, in that the same is not true for C-S-r or C-M-S-r etc. Yes, I understand that Meta chars are a bit special - that's the point here. We handle "\M-\S-r" and [(meta shift r)] in `define-key' as `M-R', not as `M-S-r'. But we do not do the same for (kbd "M-S-r"). Yes, I understand why: because `kbd' accepts an _external_ key representation, and the external representation of the key specified by "\M-\S-r" or [(meta shift r)] is `M-R', not `M-S-r'. AFAICT, there is _no_ possible key with external key representation `M-S-r'. That is, a user cannot effect such a key sequence. And yet `kbd' accepts that arg and `define-key' etc. happily creates a binding for it. > The key S-r (lowercase r with shift modifier) is different from > R (uppercase R), One of my questions was this: To what actual keys does the former correspond? How can a "lowercase r with shift modifier" key ever be manifested by a user? If it could never be (via keyboard or some other way), then why do we accept it (and silently)? > but the keyboard input always translates Shift + lowercase > letter to the corresponding upper case letter, so it is > impossible to input S-r. See above. If it is impossible to manifest a `S-r' key sequence, then why do we accept it for binding? Why do we actually create a binding to a key that no user could ever realize? Note too that for programmatic creation of bindings using `kbd', it can be handy to handle the shift modifier the same as the others in a program, and to handle the meta and control modifiers equally. And it would be convenient if `S-r' were, when used without a control modifier, automatically translated to `R' (e.g., before the rest of the `kbd' processing). That's how I stumbled across this: with code that treated the modifiers the same way. It defined `M-S-r' the same way it defined `C-S-r'. So it ended up defining a key that no one can type. And it took me a while to discover the problem, as I was mistakenly thinking of `M-S-r' and `C-S-r' in the same way. When trying to test/debug, I pressed Meta, Shift, and `r' and not get the effect I was mistakenly expecting for `M-S-r'. Another way to think of that proposal might be to consider `M-S-r' as another, equivalent external representation for the key currently represented only as `M-R'. The bottom line is that there is a degree of inconsistency that can lead to confusion. At least it did in my case, and I was already aware of how Meta characters work and the fact that there is no `C-R' etc. See above for possible proposals: either (a) have `kbd' or `define-key' reject such impossible key sequences or (b) allow `M-S-r' as an additional external representation (for `kbd') equivalent to `M-R', i.e., automatically translate it in `kbd'. Maybe there are other, better proposals. A workaround for the problem, if you decide not to fix it, is to try to dispel confusion by covering it explicitly in the Elisp manual.