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: Mon, 22 Apr 2002 05:28:42 -0400 Sender: emacs-devel-admin@gnu.org Message-ID: <200204220928.g3M9Sgq32304@rum.cs.yale.edu> References: <5xbscpg7zl.fsf@kfs2.cua.dk> <200204112243.g3BMhmI01190@rum.cs.yale.edu> <5xd6x5i7ps.fsf@kfs2.cua.dk> <5x4rih12b2.fsf@kfs2.cua.dk> <200204121846.g3CIkZY16909@rum.cs.yale.edu> <5xofgoobzr.fsf@kfs2.cua.dk> <200204122021.g3CKLh217680@rum.cs.yale.edu> <5xu1qd29od.fsf@kfs2.cua.dk> <200204162018.g3GKI3S24358@aztec.santafe.edu> <5x662rxog2.fsf@kfs2.cua.dk> <200204181846.g3IIk2K00596@aztec.santafe.edu> <5xk7r4mwqs.fsf@kfs2.cua.dk> <200204191343.g3JDh1V09176@rum.cs.yale.edu> <5xn0vz8zv3.fsf@kfs2.cua.dk> <200204191446.g3JEk2w09743@rum.cs.yale.edu> <5xy9fhj66p.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 1019469067 2653 127.0.0.1 (22 Apr 2002 09:51:07 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Mon, 22 Apr 2002 09:51:07 +0000 (UTC) Cc: "Stefan Monnier" , 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 16zaTT-0000gf-00 for ; Mon, 22 Apr 2002 11:51:07 +0200 Original-Received: from fencepost.gnu.org ([199.232.76.164]) by quimby.gnus.org with esmtp (Exim 3.12 #1 (Debian)) id 16zaU6-0000Nb-00 for ; Mon, 22 Apr 2002 11:51:47 +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 16za9m-0006bk-00; Mon, 22 Apr 2002 05:30:46 -0400 Original-Received: from rum.cs.yale.edu ([128.36.229.169]) by fencepost.gnu.org with esmtp (Exim 3.34 #1 (Debian)) id 16za7r-0006Bu-00 for ; Mon, 22 Apr 2002 05:28:47 -0400 Original-Received: (from monnier@localhost) by rum.cs.yale.edu (8.11.6/8.11.6) id g3M9Sgq32304; Mon, 22 Apr 2002 05:28:42 -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:3008 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:3008 > "Stefan Monnier" writes: > > > > "Stefan Monnier" writes: > > > > I haven't heard any comment about my proposal to use `menu-item' > > > > bindings with a :enable setting in order to get conditional bindings > > > > (this doesn't currently work, but it should be pretty easy to make > > > > it work). > > > > Would it help you solve your problems ? > > > > > > Considering that cua has approx 100 bindings in 7 keymaps, > > > it seems like absolute overkill IMO to condition each of those > > > 100 bindings individually instead of just the 7 keymaps which > > > contain those bindings... > > > > Is that 7*100 bindings or 7*14 bindings ? > > It is 8 + 7 + 2 + 10 + 17 + 60 + 16 bindings... So, more like 7*14. How many of those bindings are in submaps (rather in the toplevel maps) such that the :enable condition could be put on the prefix and thus shared ? > > How much overlap ? > None. You mean that C-x is only bound in one of those 7 keymaps ? But if there's no overlap, then the order of those maps relative to each other is irrelevant. > > How many different conditions would there be ? > There are 7 different conditions. If there's really no overlap and thus only 7 conditions, then the only difference between my proposal and yours is that in my proposition the condition is put on each binding inside the toplevel map rather than being "outside the toplevel". So the situation is very much like the use of :filter. Actually we could use :filter to get the :enable behavior without any change to the C code at all. I.e. if a binding was made like (define-key cua-foo-map key bind) and assuming that the conditional corresponding to cua-foo-map is cua-foo-predicate, the new code would simply do: (defun cua-foo-filter (b) (if (eval cua-foo-predicate) b)) (define-key cua-mode-map key '(menu-item "bla" bind :filter cua-foo-filter)) > > For the sake of describe-key, I think it's better to have fewer bindings > > (with the dispatch done more often in the bound function rather > > than in the :enable conditionals) so that the docstring can describe what > > happens when. > > I don't think you will see any difference whether this is done > via conditions in the minor-mode-map-alist (or emulation-mode-map-alist), > or by conditioning each command individually. I was assuming that there would be overlap between the maps such that C-x is bound in several of your maps, so that C-h k would point you to a different function/docstring depending on the circumstance. Whereas if the conditional is tested inside the C code, then C-h k gets you to the function that can then conveniently describe the difference circumstances and their effect. Of course, if there's no overlap, there's indeed no difference. > Also, I don't see why it is better to eval the various conditions 100 times > rather than just 7 times? I don't see why the condition should be evaluated more times with my proposal than with yours. Actually, in your proposal, 7 conditions are being evaluated for each command (they're evaluated right at the beginning, in order to know which keymaps to look up), whereas in mine only between 1 and 7 conditions would be evaluated (if there's no overlap between the 7 maps, only 1, but if the current key pressed is present in all 7 of your maps, then 7). Stefan