From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Richard Stallman Newsgroups: gmane.emacs.devel Subject: Re: Customizing key bindings Date: Mon, 09 Sep 2002 19:33:44 -0400 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: rms@gnu.org NNTP-Posting-Host: localhost.gmane.org X-Trace: main.gmane.org 1031614788 11834 127.0.0.1 (9 Sep 2002 23:39:48 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Mon, 9 Sep 2002 23:39:48 +0000 (UTC) Cc: abraham@dina.kvl.dk, alex@emacswiki.org, 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 17oY8B-00034j-00 for ; Tue, 10 Sep 2002 01:39:47 +0200 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.12 #1 (Debian)) id 17oYiK-0000dB-00 for ; Tue, 10 Sep 2002 02:17:08 +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 17oY8E-0004f1-00; Mon, 09 Sep 2002 19:39:50 -0400 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.10) id 17oY2N-0003Al-00 for emacs-devel@gnu.org; Mon, 09 Sep 2002 19:33:47 -0400 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.10) id 17oY2K-00039I-00 for emacs-devel@gnu.org; Mon, 09 Sep 2002 19:33:46 -0400 Original-Received: from fencepost.gnu.org ([199.232.76.164]) by monty-python.gnu.org with esmtp (Exim 4.10) id 17oY2K-00039C-00 for emacs-devel@gnu.org; Mon, 09 Sep 2002 19:33:44 -0400 Original-Received: from rms by fencepost.gnu.org with local (Exim 4.10) id 17oY2K-0005yX-00; Mon, 09 Sep 2002 19:33:44 -0400 Original-To: miles@gnu.org In-reply-to: (message from Miles Bader on 09 Sep 2002 18:19:59 +0900) 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:7777 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:7777 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. In my two-keymap proposal, the second one is found only as the parent of the first. The first is marked somehow as a customization keymap so that define-key knows to keep moving and define in its parent. My two-keymap proposal is #1 below. ====================================================================== Here's what I think the :set for a keymap should do. Actually, I have two alternative ideas: 1. Create a new keymap, as above, but make its parent be the keymap that was the value of SYM before. Put the symbol `custom' in the keymap to mark it as made here. If Custom had already run and done this, strip off the keymap it made before, and make a new one. Change define-key so that it skips that keymap and makes the change in the parent. Now all changes made outside Custom will be permanent. However, the bindings specified with Custom will shadow those changes. In some cases the user might not like that, but I don't see that any alternative is clearly better. [In fact, it seems to me that this is more correct than any other alternative.] 2. Instead of making a new keymap, just install the changes in the original keymap, saving the original definitions. More precisely, here's what :set would do: * Reinstall all the saved original bindings * For each key that has a Custom key binding, save is current binding. * Install the Custom key bindings. This way, changes made outside Custom all take effect immediately. If the key has no Custom binding, the change is permanent. If the key does have a Custom binding, the change is lost when Custom runs again, but maybe that is reasonable in this case.