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: Bikeshedding "user choice" Date: Wed, 19 Jan 2011 11:34:18 -0800 Message-ID: References: <87sjx7z7w4.fsf@telefonica.net><83pqsbmf6j.fsf@gnu.org><87k4ijz07h.fsf@telefonica.net><2460D97DEA4047B3B9DF92C4A80981EF@us.oracle.com><57BF13882D6E494286547F293FE9D03B@us.oracle.com><87lj2pfo81.fsf@wanadoo.es><3311B7BF884147FFB4ADD5FEB31F1F39@us.oracle.com><227F94B0AC1649C1A41082A24!9921783@us.oracle!! ! .com><3BA19D85DE954C00B3CC7A7C8A0BD32C@us.oracle.com><87tyh67v9y.fsf@uwakimon.sk.tsukuba.ac.jp><87oc7e7ncz.fsf@uwakimon.sk.tsukuba.ac.jp><69C57932AE034639B76F279086EA9DA9@us.oracle.com> <87ipxl7alc.fsf@uwakimon.sk.tsukuba.ac.jp> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Trace: dough.gmane.org 1295465751 15477 80.91.229.12 (19 Jan 2011 19:35:51 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Wed, 19 Jan 2011 19:35:51 +0000 (UTC) Cc: 'Emacs-Devel devel' To: "'Stephen J. Turnbull'" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Jan 19 20:35:47 2011 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Pfdoo-0001Hn-G8 for ged-emacs-devel@m.gmane.org; Wed, 19 Jan 2011 20:35:46 +0100 Original-Received: from localhost ([127.0.0.1]:43082 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Pfdon-0002CG-5y for ged-emacs-devel@m.gmane.org; Wed, 19 Jan 2011 14:35:45 -0500 Original-Received: from [140.186.70.92] (port=44340 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Pfdod-00028t-18 for emacs-devel@gnu.org; Wed, 19 Jan 2011 14:35:36 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Pfdob-0003kg-H7 for emacs-devel@gnu.org; Wed, 19 Jan 2011 14:35:34 -0500 Original-Received: from rcsinet10.oracle.com ([148.87.113.121]:64627) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Pfdob-0003ju-BM for emacs-devel@gnu.org; Wed, 19 Jan 2011 14:35:33 -0500 Original-Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id p0JJZSEx008240 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 19 Jan 2011 19:35:30 GMT Original-Received: from acsmt354.oracle.com (acsmt354.oracle.com [141.146.40.154]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id p0JGKdWL007575; Wed, 19 Jan 2011 19:35:28 GMT Original-Received: from abhmt017.oracle.com by acsmt355.oracle.com with ESMTP id 937648241295465658; Wed, 19 Jan 2011 11:34:18 -0800 Original-Received: from dradamslap1 (/130.35.179.10) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 19 Jan 2011 11:34:18 -0800 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <87ipxl7alc.fsf@uwakimon.sk.tsukuba.ac.jp> Thread-Index: Acu3lo7c5w7dQqv4QkalOWXiIQ+rvgAYlPjw X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5994 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:134772 Archived-At: > > Calm down, please; no need to shout. > > That was not "shouting", that was the 2x4 which seems to be essential > for getting the mule's attention. And no need for name-calling. > nobody proposes to change Emacs's behavior with respect to > unbound keys. Lennart ... proposes to allow implicit binding > via the GUI environment, as well as explicit binding within > Emacs. Ie, his proposal is really to change the definition of > "bound". A radical change to the definition of "bound" for Emacs is a proposal to change Emacs's behavior wrt unbound keys. > Lennart wants "delegate to OS" to be the fallback for *all* keys, > *not* restricted to M-F4.... currently the default is "if Emacs > doesn't explicitly bind a key, by default stroking it leads to > an error", and Lennart proposes to change that default to "if > Emacs doesn't explicitly bind a key, look a little harder to see > if the environment binds it." > > What Lennart wants, as far as I can tell, is > (1) Emacs can explicitly (un)bind a key (the "unbound" state is > achieved with `(define-key map key nil)'). In case of an > explicitly unbound keystroke, Emacs will signal an unbound error. > (2) If (1) does not hold, then Emacs will *implicitly* bind the key to > an action determined by the GUI if the GUI defines one. > (3) If neither (1) nor (2) holds, Emacs signals an unbound error when > the key is stroked. > > This is a change in the definition of "binding". I understood Lennart the same way (except that as he pointed out it is an unbound message, not an unbound error). I disagree that this is the right approach. I prefer that the set of keys for which pass-through is currently effective be explicit within Emacs, for users and Lisp. If each key for which we want pass-through has an Emacs binding that specifies this (pass-through), then it is clear to everyone what that key does in Emacs (it is handled by the OS). Likewise, for Stefan's alternative of using `w32-passthrough-events'. Otherwise (in Lennart's proposal as you have described it): 1. To turn off this behavior globally, you must bind each Windows hotkey to nil explicitly (unless it is already bound to an Emacs command). How do you find all such hotkeys? Examine the Windows doc... But wait?! Applications and hardware OEMs can assign Windows hot keys too. How do you find them all? Search the registry? 2. Since "bound" would have a new meaning in Emacs, what would key lookup mean/do? Until now, being unbound has been effectively the same as having a nil binding. And your (1) above maintains that terminology - OK. So now how does your code distinguish "unbound" as a nil binding from "neither bound or unbound" (no explicit binding, either command or nil)? If M-f4 is not bound to nil or to a command then is it unbound? bound? Well, your (2) says that Emacs will have *implicitly* bound it to a GUI action (if available). Sometimes people mean "automatically" when they say "implicitly", so let's check: Does "implicit" here mean just automatic, so that once this binding has been created automatically it is seen in Emacs Lisp as a (normal) binding? Or is there never any Emacs binding, just a virtual, extra-Emacs binding? In the latter case (which I'm guessing you mean), how can Lisp code determine whether a given key has an effect (let alone what that effect might be)? Will `lookup-key' change, or will it still return nil for a key that has not been given any explicit binding (nil or otherwise)? In the latter case it does not distinguish a key that will be handled by Windows from a key which has been explicitly bound to nil. It is far better IMO to make such connections between keys and actions explicit, for Emacs users and at the Lisp level. Use an explicit Emacs binding: (define-key KEY 'w32-syskey). Or use an explicit mapping variable such as `w32-passthrough-events'. Users and Lisp code can then see what's happening, and it is trivial to turn it off, all of it. And if tomorrow some new app or new hardware changes Windows to add its own global hotkey, then nothing changes in Emacs (POLA), since the key was not added at the Emacs level (binding to `w32-syskey', or `w32-passthrough-events entry). What Emacs users and code see, in Emacs, is what they get.