From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Per Abrahamsen Newsgroups: gmane.emacs.devel Subject: Re: Customizing key bindings Date: Mon, 09 Sep 2002 14:20:33 +0200 Organization: The Church of Emacs 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> NNTP-Posting-Host: localhost.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: main.gmane.org 1031574191 3928 127.0.0.1 (9 Sep 2002 12:23:11 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Mon, 9 Sep 2002 12:23:11 +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 17oNZO-00011E-00 for ; Mon, 09 Sep 2002 14:23:10 +0200 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.12 #1 (Debian)) id 17oO9J-0001B4-00 for ; Mon, 09 Sep 2002 15:00:18 +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 17oNZP-0008Sw-00; Mon, 09 Sep 2002 08:23:11 -0400 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.10) id 17oNXV-0008OH-00 for emacs-devel@gnu.org; Mon, 09 Sep 2002 08:21:13 -0400 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.10) id 17oNXT-0008Nx-00 for emacs-devel@gnu.org; Mon, 09 Sep 2002 08:21:12 -0400 Original-Received: from sheridan.dina.kvl.dk ([130.225.40.227]) by monty-python.gnu.org with esmtp (Exim 4.10) id 17oNXQ-0008Na-00; Mon, 09 Sep 2002 08:21:08 -0400 Original-Received: from zuse.dina.kvl.dk (zuse.dina.kvl.dk [130.225.40.245]) by sheridan.dina.kvl.dk (8.9.3/8.9.3/Debian 8.9.3-21) with ESMTP id OAA19198; Mon, 9 Sep 2002 14:20:39 +0200 Original-Received: (from abraham@localhost) by zuse.dina.kvl.dk (8.9.3+Sun/8.9.3) id OAA06687; Mon, 9 Sep 2002 14:20:34 +0200 (MEST) X-Authentication-Warning: zuse.dina.kvl.dk: abraham set sender to abraham@dina.kvl.dk using -f Original-To: Miles Bader X-Face: +kRV2]2q}lixHkE{U)mY#+6]{AH=yN~S9@IFiOa@X6?GM|8MBp/ In-Reply-To: (Miles Bader's message of "09 Sep 2002 18:19:59 +0900") Original-Lines: 78 User-Agent: Gnus/5.090007 (Oort Gnus v0.07) Emacs/21.1 (sparc-sun-solaris2.8) 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:7744 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:7744 Miles Bader writes: > 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. Only for bundled packages. > Non-trival differences in behavior based on (interactive-p) are > something that make me nervous. Me too, but nobody protested when Stefan added such functionality to define-minor-mode, so I presumed it was an acceptable solution. > 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) Yes. I find this this simple and intuitive. > So is there a definition of `user' that's easy to implement? I define "user" to be someone who use the interactive fascilities for customizing Emacs, rather than the Lisp fascilities for the same. > I'm not sure, maybe something like `not defined while loading a > file'. That may be more reliable, rather than, as now, gradually making existing commands customize aware, as people think of them. E.g. set-variable should probably really be customize aware when called interactively. > 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. They should be "non-user", as we don't want customize to duplicate these bindings on start-up. > Note that this sort of test could be done entirely within `define-key', > and wouldn't have to distinguish between customization and other uses. Cool. Do you want to propose the same for "setq" ;-) > 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. I probably shouldn't say this, but it will be simpler for XEmacs, where keymaps are an opaque type.