From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: "Stefan Monnier" Newsgroups: gmane.emacs.devel Subject: Re: Enhancements to "minor-mode-map-alist" functionality. Date: Thu, 11 Apr 2002 18:43:48 -0400 Sender: emacs-devel-admin@gnu.org Message-ID: <200204112243.g3BMhmI01190@rum.cs.yale.edu> References: <5xbscpg7zl.fsf@kfs2.cua.dk> NNTP-Posting-Host: localhost.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: main.gmane.org 1018565155 25382 127.0.0.1 (11 Apr 2002 22:45:55 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Thu, 11 Apr 2002 22:45:55 +0000 (UTC) Cc: emacs-devel@gnu.org Return-path: Original-Received: from quimby.gnus.org ([80.91.224.244]) by main.gmane.org with esmtp (Exim 3.33 #1 (Debian)) id 16vnKF-0006bH-00 for ; Fri, 12 Apr 2002 00:45:55 +0200 Original-Received: from fencepost.gnu.org ([199.232.76.164]) by quimby.gnus.org with esmtp (Exim 3.12 #1 (Debian)) id 16vnaE-0005ML-00 for ; Fri, 12 Apr 2002 01:02:26 +0200 Original-Received: from localhost ([127.0.0.1] helo=fencepost.gnu.org) by fencepost.gnu.org with esmtp (Exim 3.34 #1 (Debian)) id 16vnJj-00053l-00; Thu, 11 Apr 2002 18:45:23 -0400 Original-Received: from rum.cs.yale.edu ([128.36.229.169]) by fencepost.gnu.org with esmtp (Exim 3.34 #1 (Debian)) id 16vnIE-0004z2-00 for ; Thu, 11 Apr 2002 18:43:50 -0400 Original-Received: (from monnier@localhost) by rum.cs.yale.edu (8.11.6/8.11.6) id g3BMhmI01190; Thu, 11 Apr 2002 18:43:48 -0400 X-Mailer: exmh version 2.4 06/23/2000 with nmh-1.0.4 Original-To: storm@cua.dk (Kim F. Storm) Errors-To: emacs-devel-admin@gnu.org X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.0.9 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Emacs development discussions. List-Unsubscribe: , List-Archive: Xref: main.gmane.org gmane.emacs.devel:2554 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:2554 > However, this can be dramatically simplified by two (simple) > enhancements to the minor-mode-map-alist functionality: > > 1) Provide a separate emulation-mode-map-alists variable where > modes like cua can insert their own mode-map-alist, As you probably know, I'm not too excited about this, since it shouldn't be necessary if we could enforce a bit more discipline in the way entries are added to minor-mode-map-alist. [ Yes, I wish we had "watchers" so we could trap modifications of particular variables. ] But I guess that I can live with it. BTW, should emulation-mode-map-alists take precedence over minor-mode-overriding-map-alist or not ? Also, have you contacted Michael Kifer to see if that would satisfy his needs for viper (I know he also had to do some funky post-command fiddling of the minor-mode-map-alist). > 2) Allow selection of the active keymaps in the alist to > be based on evaluating a form in addition to a simple variable. I generally like the idea of having the keymaps more dynamic, but I'd rather not add another form of dynamism that isn't quite good enough for everything. To be more precise, currently you can get the above "select the keymap dynamically" in a more generic way (i.e. not just for minor mode maps) by using an entry of the form: '(menu-item "foo" data :filter fun) It is mostly used for dynamic menus, but also works in other keymaps. Problem is, it only works for submaps because it is not itself a keymap and thus can't be used for a toplevel map. So if the dynamism you need is only in the `command-remap' submap, for example, your new hack is not needed. I'd rather not add a hack that's specific to minor-mode-map-alist if we could do the same for all cases instead. > I have already implemented these features (see attached patch), > which allows me to configure all the minor mode keymaps needed > by cua once and for all: In the patch, you end up evaluating elisp code from a function that already has a comment about the fact that it needs to be extra-careful about memory allocation. Also I'm not sure that all places that call this function are ready to have elisp code executed at that point (you might need some GCPROs added here and there). In other words, maybe we shouldn't evaluate the form inside this current_minor_maps function. Stefan PS: by the way, isn't it enough to fiddle with minor-mode-map-alist in after-load-hook rather than in post-command-hook ? [ assuming we had such an after-load-hook. ]