From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: storm@cua.dk (Kim F. Storm) Newsgroups: gmane.emacs.devel Subject: Re: Enhancements to "minor-mode-map-alist" functionality. Date: 22 Apr 2002 17:15:59 +0200 Sender: emacs-devel-admin@gnu.org Message-ID: <5xadrvkbm8.fsf@kfs2.cua.dk> 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> <200204220928.g3M9Sgq32304@rum.cs.yale.edu> NNTP-Posting-Host: localhost.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: main.gmane.org 1019485111 27265 127.0.0.1 (22 Apr 2002 14:18:31 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Mon, 22 Apr 2002 14:18:31 +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 16zeeF-00075e-00 for ; Mon, 22 Apr 2002 16:18:31 +0200 Original-Received: from fencepost.gnu.org ([199.232.76.164]) by quimby.gnus.org with esmtp (Exim 3.12 #1 (Debian)) id 16zeey-0006Rj-00 for ; Mon, 22 Apr 2002 16:19:17 +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 16zedz-0000db-00; Mon, 22 Apr 2002 10:18:15 -0400 Original-Received: from mail.filanet.dk ([195.215.206.179]) by fencepost.gnu.org with smtp (Exim 3.34 #1 (Debian)) id 16zeb6-0000S1-00 for ; Mon, 22 Apr 2002 10:15:16 -0400 Original-Received: from kfs2.cua.dk.cua.dk (unknown [10.1.82.3]) by mail.filanet.dk (Postfix) with SMTP id 404FB7C047; Mon, 22 Apr 2002 14:15:11 +0000 (GMT) Original-To: "Stefan Monnier" In-Reply-To: <200204220928.g3M9Sgq32304@rum.cs.yale.edu> Original-Lines: 223 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2.50 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:3036 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:3036 "Stefan Monnier" writes: > > "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. Oh, sorry I don't know why I said that.... Of course there is some overlap between some of those keymaps. E.g. C-x is bound in various ways in three of the keymaps, and `kill-ring-save' is remapped differently in three other keymaps. See the completely list of bindings (with overlap) at the end of this message. > > > > 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)) Yes, I can see the potential. AFAICS, the overlap can be handled by something like this: (defun cua-krs-filter (b) (cond (cua-global-mark-active 'cua-kill-to-global-mark) (cua-rectangle 'cua-kill-rectangle) (mark-active 'cua-kill-region) (t nil))) (define-key cua-mode-map [remap kill-ring-save] '(menu-item "-" nil :filter cua-krs-filter)) But that would not be practical for cua (too much overlap). > > > > 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. > Exactly. > 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). I stand corrected. Again, I'm sorry about the misinformation re. overlap. But I still fail to see how this approach can address all the requirements for cua. Here is the complete list of keymaps and bindings used by cua in its current state: 1 - cua--prefix-override-keymap . 2 - cua--prefix-repeat-keymap . . 3 - cua--cua-keys-keymap . . . 4 - cua--global-mark-keymap . . . . 5 - cua--rectangle-keymap . . . . . 6 - cua--region-keymap Key binding . . . . . . 7 - cua--global-keymap (* indicates remap) . . . . . . . ----------------------------------------------------------------------------- C-x 1 (2) (3) C-c 1 (2) (3) C-x C-x (1) 2 C-x up (1) 2 C-x down (1) 2 C-x left (1) 2 C-x right (1) 2 C-x timeout (1) 3 S-C-x 3 C-c C-c (1) 2 C-c up (1) 2 C-c down (1) 2 C-c left (1) 2 C-c right (1) 2 C-c timeout (1) 3 S-C-c 3 C-z 3 C-v 3 RET 4 5 TAB 5 S-return 5 6 7 H-space 5 6 7 mouse-1 5 down-mouse-1 5 drag-mouse-1 5 mouse-3 5 down-mouse-3 5 drag-mouse-3 5 H-mouse-1 7 S-C-SPC 7 C-? 5 M-up 5 M-down 5 M-left 5 M-right 5 C-M-up 5 C-M-down 5 M-a 5 M-b 5 M-c 5 M-f 5 M-F 5 M-i 5 M-k 5 M-l 5 M-m 5 M-n 5 M-o 5 M-p 5 M-P 5 M-r 5 M-R 5 M-s 5 M-t 5 M-u 5 M-| 5 M-' 5 M-/ 5 *exchange-point-and-mark 3 *yank 4 7 *clipboard-yank 7 *yank-pop 7 *set-mark-command 5 7 *undo 7 *advertised-undo 7 *self-insert-command 4 5 6 *self-insert-iso 4 5 6 *insert-register 6 *newline-and-indent 4 6 *newline 4 6 *open-line 6 *delete-backward-char 4 5 6 *backward-delete-char 4 5 6 *backward-delete-char-untabify 4 5 6 *delete-char 4 5 6 *kill-region 4 5 6 *copy-region-as-kill 4 5 6 *kill-ring-save 4 5 6 *keyboard-escape-quit 4 6 *keyboard-quit 4 6 *forward-char 5 *backward-char 5 *next-line 5 *previous-line 5 *end-of-line 5 *beginning-of-line 5 *end-of-buffer 5 *beginning-of-buffer 5 *scroll-down 5 *scroll-up 5 -- Kim F. Storm http://www.cua.dk