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: [CVS] f7, f8 bound.. Date: Fri, 6 Sep 2002 18:19:57 -0400 Sender: emacs-devel-admin@gnu.org Message-ID: <20020906221957.GB7270@gnu.org> References: <20020903130247.GA6318@gnu.org> <20020903173120.GA29981@gnu.org> <87ptvttnyo.fsf@emacswiki.org> NNTP-Posting-Host: localhost.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: main.gmane.org 1031364024 18909 127.0.0.1 (7 Sep 2002 02:00:24 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Sat, 7 Sep 2002 02:00:24 +0000 (UTC) Cc: emacs-devel@gnu.org Return-path: Original-Received: from hermes.netfonds.no ([80.91.224.195]) by main.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 17nUWM-0001pj-00 for ; Sat, 07 Sep 2002 03:36:22 +0200 Original-Received: from mail-relay.eunet.no (mail-relay.eunet.no [193.71.71.242]) by hermes.netfonds.no (8.12.1/8.12.1) with ESMTP id g86MMC9e017702 for ; Sat, 7 Sep 2002 00:22:12 +0200 (CEST) Original-Received: from quimby.gnus.org (quimby.gnus.org [80.91.224.244]) by mail-relay.eunet.no (8.12.2/8.12.2/GN) with ESMTP id g86MMCRb057977 for ; Sat, 7 Sep 2002 00:22:12 +0200 (CEST) (envelope-from emacs-devel-admin@gnu.org) Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.12 #1 (Debian)) id 17nS37-0004nS-00 for ; Sat, 07 Sep 2002 00:58: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 17nRUQ-0001L6-00; Fri, 06 Sep 2002 18:22:10 -0400 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.10) id 17nRSM-0000xt-00 for emacs-devel@gnu.org; Fri, 06 Sep 2002 18:20:02 -0400 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.10) id 17nRSI-0000x8-00 for emacs-devel@gnu.org; Fri, 06 Sep 2002 18:20:00 -0400 Original-Received: from fencepost.gnu.org ([199.232.76.164]) by monty-python.gnu.org with esmtp (Exim 4.10) id 17nRSI-0000wt-00 for emacs-devel@gnu.org; Fri, 06 Sep 2002 18:19:58 -0400 Original-Received: from miles by fencepost.gnu.org with local (Exim 4.10) id 17nRSI-0002Gy-00; Fri, 06 Sep 2002 18:19:58 -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:7659 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:7659 On Fri, Sep 06, 2002 at 12:07:51PM +0200, Per Abrahamsen wrote: > >> With your code, the rules are simle: If you change a keymap with > >> customize, all other changes are lost. With such a simple rule, the > >> rest of the world can comply. > > > > That's obviously a simple rule, but it's also silly and bad; if that's > > what the current code does, then it's not usable. > > Why "not usable"? Because it's `brittle', and makes customize incompatible with with non-customize use, which is something we want to avoid (well, maybe you don't want to avoid it, but I do). The way keymaps are handled, traditionally, is via incremental modification, not simply `setting' them, and customize should be no different. In any case, it doesn't really seem that hard to do better -- customize should only ever add or remove entries from keymaps, not `set the keymap,' and it should keep track of which ones it did, and only save those when saving. One way to do this is just have an alist of (MAP-VAR ADDED DEL'D) entries (where ADDED and DEL'D are lists of keys). > Well, it is not usable for the global map, too many packages write to > that, but packages writing directly to mode maps aren't that common. The problem is not `packages writing to mode maps,' it's _users_. Many people set keybindings in mode hooks and the like; sometimes they've copied that code from other people and don't really understand it. The `trash everything' approach obviously messes this up. The `incremental' approach I mention above is much kinder. > For the global map, maybe we can get dispensation to use two keymaps. Not if I can help it. > > Your two variable solution has a similar problem, BTW -- if > > e.g. `custom-global-map' overrides `global-map', and someone has bound a > > key via custom, and tries to re-bind it using `M-x global-set-key' -- > > then his new binding will be effectively ignored! > > True, I haven't though of using non-customize functions interactively. > They would have had to be modified in order to make the two keymap > solution a 100% solution. Are you suggesting they modify the customize keymap too? In other words all commands modify _one_ keymap? In that case you're basically using one keymap, so why not drop the pretense, and just use one for real? [Maybe you're suggesting that interactive and `non-interactive' (e.g. invoked by `M-:') uses of global-set-key work differently, but I think that's unacceptable.] The more I think about it, the more I think the two keymap solution is confusing, both to programmers _and_ users, and that an incremental one keymap solution (see above) is what we should use. -Miles -- P.S. All information contained in the above letter is false, for reasons of military security.