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: Mon, 9 Sep 2002 10:09:30 -0400 Sender: emacs-devel-admin@gnu.org Message-ID: <20020909140930.GC18843@gnu.org> References: <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 1031580847 24659 127.0.0.1 (9 Sep 2002 14:14:07 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Mon, 9 Sep 2002 14:14:07 +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 17oPIf-0006Ot-00 for ; Mon, 09 Sep 2002 16:14:01 +0200 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.12 #1 (Debian)) id 17oPsc-0003rg-00 for ; Mon, 09 Sep 2002 16:51:11 +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 17oPIi-0006zp-00; Mon, 09 Sep 2002 10:14:04 -0400 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.10) id 17oPEM-0006Tt-00 for emacs-devel@gnu.org; Mon, 09 Sep 2002 10:09:34 -0400 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.10) id 17oPEJ-0006SZ-00 for emacs-devel@gnu.org; Mon, 09 Sep 2002 10:09:34 -0400 Original-Received: from fencepost.gnu.org ([199.232.76.164]) by monty-python.gnu.org with esmtp (Exim 4.10) id 17oPEJ-0006ST-00 for emacs-devel@gnu.org; Mon, 09 Sep 2002 10:09:31 -0400 Original-Received: from miles by fencepost.gnu.org with local (Exim 4.10) id 17oPEI-0005ky-00; Mon, 09 Sep 2002 10:09:30 -0400 Original-To: Per Abrahamsen Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.28i Blat: Foop 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:7750 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:7750 On Mon, Sep 09, 2002 at 02:20:33PM +0200, Per Abrahamsen wrote: > 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: ... > Yes. I find this this simple and intuitive. Er, you omitted my additional definition, which abstracts things a bit more; does that mean you find a problem with it? > > 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. Unfortunately, that doesn't really match a typical emacs user; emacs users use `lisp' facilities to define keys all the time. I know you're coming from the point of view where customize is more important, but please try to understand that many of us wish to at least _try_ to make both sets of users happy. > > 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. I'm not sure what you mean by `duplicate on start-up' -- if .emacs bindings are marked as `user bindings' then they won't overwrite the `binding defaults' for the keys they define; if custom then defines any of the same bindings, it will overwrite the _user_ bindings, but not the `binding defaults'. So there's no `duplication', just redefinition -- just as if you had used customize to define the same key twice. The benefit of making .emacs bindings `user bindings' is that people can't use `revert to default binding' to get rid of a (non-custom) .emacs binding and go back to the binding established by the default emacs code, which many people would find intuive I think. > I probably shouldn't say this, but it will be simpler for XEmacs, > where keymaps are an opaque type. Perhaps in theory, but in practice I think that's not true -- there are so many wierd twists in the keymap format that no one in their right mind actually modifies them without using standard keymap functions. As far as I can see the only real use of the non-opaque keymaps is that it's easy to print them out and see what's in there... -Miles -- P.S. All information contained in the above letter is false, for reasons of military security.