From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Miles Bader Newsgroups: gmane.emacs.devel Subject: Re: Customizing key bindings Date: 09 Sep 2002 18:19:59 +0900 Sender: emacs-devel-admin@gnu.org Message-ID: References: <20020903130247.GA6318@gnu.org> <20020903173120.GA29981@gnu.org> <87ptvttnyo.fsf@emacswiki.org> <200209061736.g86HaDi00352@rum.cs.yale.edu> <874rd1ki2s.fsf_-_@emacswiki.org> <20020907234343.GC26845@gnu.org> Reply-To: Miles Bader NNTP-Posting-Host: localhost.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: main.gmane.org 1031563322 8313 127.0.0.1 (9 Sep 2002 09:22:02 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Mon, 9 Sep 2002 09:22:02 +0000 (UTC) Cc: Alex Schroeder , emacs-devel@gnu.org Return-path: Original-Received: from quimby.gnus.org ([80.91.224.244]) by main.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 17oKk3-00029P-00 for ; Mon, 09 Sep 2002 11:21:59 +0200 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.12 #1 (Debian)) id 17oLJu-0005JP-00 for ; Mon, 09 Sep 2002 11:59:02 +0200 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.10) id 17oKk5-0004YO-00; Mon, 09 Sep 2002 05:22:01 -0400 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.10) id 17oKiI-0004Ps-00 for emacs-devel@gnu.org; Mon, 09 Sep 2002 05:20:10 -0400 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.10) id 17oKiF-0004Nh-00 for emacs-devel@gnu.org; Mon, 09 Sep 2002 05:20:09 -0400 Original-Received: from tyo201.gate.nec.co.jp ([210.143.35.51]) by monty-python.gnu.org with esmtp (Exim 4.10) id 17oKiE-0004Kh-00; Mon, 09 Sep 2002 05:20:06 -0400 Original-Received: from mailgate4.nec.co.jp ([10.7.69.195]) by TYO201.gate.nec.co.jp (8.11.6/3.7W01080315) with ESMTP id g899K2E25572; Mon, 9 Sep 2002 18:20:02 +0900 (JST) Original-Received: from mailsv.nec.co.jp (mailgate51.nec.co.jp [10.7.69.196]) by mailgate4.nec.co.jp (8.11.6/3.7W-MAILGATE-NEC) with ESMTP id g899K2g25450; Mon, 9 Sep 2002 18:20:02 +0900 (JST) Original-Received: from mcsss2.ucom.lsi.nec.co.jp ([10.30.114.133]) by mailsv.nec.co.jp (8.11.6/3.7W-MAILSV-NEC) with ESMTP id g899K0e16461; Mon, 9 Sep 2002 18:20:00 +0900 (JST) Original-Received: from mcspd15.ucom.lsi.nec.co.jp (mcspd15 [10.30.114.174]) by mcsss2.ucom.lsi.nec.co.jp (8.10.2+Sun/3.7Wlsi_mx_6.0) with ESMTP id g899K0s28009; Mon, 9 Sep 2002 18:20:00 +0900 (JST) Original-Received: by mcspd15.ucom.lsi.nec.co.jp (Postfix, from userid 31295) id CC8D93723; Mon, 9 Sep 2002 18:19:59 +0900 (JST) Original-To: Per Abrahamsen System-Type: i686-pc-linux-gnu Blat: Foop Original-Lines: 93 Errors-To: emacs-devel-admin@gnu.org X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.0.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Emacs development discussions. List-Unsubscribe: , List-Archive: Xref: main.gmane.org gmane.emacs.devel:7738 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:7738 Per Abrahamsen writes: > > The above situation seems rather silly (and unlikely); if `foo-extra' screws > > around like that, then I don't think we should expect custom to intuit what > > the right thing to do is. > > Such packages are common for "global-map". My first reaction was to say `true', but now that I think about it, are they? The usual way that global bindings are established is to bind the key ahead of time (often via ###autoload), and autoload the package when the binding is first invoked. In those cases, the `default binding' is established ahead of time, so customize will find it. One exception is e.g., gdb-mode (with its `C-x C-a' prefix bindings). > > ... which is a misnomer, since it's not really `100%', just 90% with a > > different 10% cut out. > > As you pointed out, it would require a "when (interactive-p)" added to > global-(un)set-key and local-(un)set-key to be a 100% solution. The truth is that to really be 100%, you have to read the users mind, and we (sadly) can't do that. Non-trival differences in behavior based on (interactive-p) are something that make me nervous. For example, someone has a bunch of (global-set-key ...) forms in his .emacs file, and notices some binding isn't as he wants it, so he does `eval-region' on them. Or he has a hook set up some bindings. In both cases, if they're shadowed by customize bindings, they act as if they don't exist, no matter how many times he evaluates them. On the other hand, the case that you cite is that when a package is loaded, it shouldn't override a customized binding (though I expect there are some occasions that users will think it should), and that if the user undoes his customization, he should get the last-executed `traditional' binding. If I can try to restate what you said, it seems to be: [a] customize-bindings override traditional bindings (with interactive uses of `global-set-key' granted honorary customize status) [b] traditional (define-key, etc) bindings provide the value for `restore default' in customize (and within each category, `customize' and `traditional', the most recent definition always supersedes previous ones) What seem better to me is this: [a] _user_ bindings override non-user bindings [b] non-user bindings provide the value for `restore default' (with the same time-ordering within each category) Where `user' is fuzzily defined to be `something the user did, not a package.' So is there a definition of `user' that's easy to implement? I'm not sure, maybe something like `not defined while loading a file'. That would catch customize, M-x global-set-key, M-: (global-set-key ...), hooks, eval-region, etc. It would also mean that bindings established in .emacs are `non-user' which may be good or bad, but maybe it could be made be an exception to the loading-files test. Note that this sort of test could be done entirely within `define-key', and wouldn't have to distinguish between customization and other uses. It's possible to implement this either as a nested set of keymaps (like you use), where the decision whether to use a `user' or `default' binding is made at key-lookup time, or to simply stash the default bindings in a different keymap for use by customize and also put them in the real keymap when appropriate. Another question is `if there the implementation uses two keymaps (either for nesting at lookup time, or just for bookkeeping purposes), where is the second one stored?' I really dislike your idea of having two separate lisp variable to store them. It oughtn't even be necessary to know the name of a keymap to find its associated `2nd keymap', especially when more than just customize is looking at them. Is it possible to stash the `2nd keymap' within the primary keymap directly? Alternatively, there could be a global alist mapping primary keymaps (note, _not_ variable names) to 2ndary keymaps. -Miles