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: Suggestion: Simple way to make conditional key bindings. Date: 27 Aug 2002 13:23:41 +0200 Sender: emacs-devel-admin@gnu.org Message-ID: <5xsn10sfya.fsf@kfs2.cua.dk> References: <3D49FF140074EFAE@mel-rta7.wanadoo.fr> <5xadnd3eck.fsf@kfs2.cua.dk> <200208231722.g7NHM0M02096@rum.cs.yale.edu> <5xptw6wm2v.fsf@kfs2.cua.dk> <200208261547.g7QFlpA24835@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 1030443845 27041 127.0.0.1 (27 Aug 2002 10:24:05 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Tue, 27 Aug 2002 10:24:05 +0000 (UTC) Cc: "David PONCE" , 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 17jdVw-00071p-00 for ; Tue, 27 Aug 2002 12:24:00 +0200 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.12 #1 (Debian)) id 17je1C-000895-00 for ; Tue, 27 Aug 2002 12:56:18 +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 17jdXA-00063m-00; Tue, 27 Aug 2002 06:25:16 -0400 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.10) id 17jdVI-0005yv-00 for emacs-devel@gnu.org; Tue, 27 Aug 2002 06:23:20 -0400 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.10) id 17jdVG-0005yh-00 for emacs-devel@gnu.org; Tue, 27 Aug 2002 06:23:19 -0400 Original-Received: from mail.filanet.dk ([195.215.206.179]) by monty-python.gnu.org with esmtp (Exim 4.10) id 17jdVF-0005yd-00 for emacs-devel@gnu.org; Tue, 27 Aug 2002 06:23:17 -0400 Original-Received: from kfs2.cua.dk.cua.dk (kfs2.local.filanet.dk [192.168.1.182]) by mail.filanet.dk (Postfix) with SMTP id 315587C019; Tue, 27 Aug 2002 10:23:16 +0000 (GMT) Original-To: "Stefan Monnier" In-Reply-To: <200208261547.g7QFlpA24835@rum.cs.yale.edu> Original-Lines: 108 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3.50 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:6978 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:6978 "Stefan Monnier" writes: > > > You want to have a code. That's what functions are for. I think `eval' > > > should generally be avoided, and `funcall' used instead. > > > This is especially true if we care about lexical scoping. > > > > I don't quite follow, but I take your word for it :-) > > When you construct a function, the Elisp interpreter/compiler knows that > it's a piece of code and can do all kinds of things with it (byte-compile > it, analyze it and put out warnings, build a closure to remember the > current lexical bindings, ...). > OTOH, when you build a piece of code to be eval'd, the Elisp > interpreter/compiler usually has no idea that this is code rather > than just some kind of list of elements, so it can't do anything > clever with it. Ok, but for the uses I can envision for the `cond' binding, there's probably not much cleverness that can be done with it... > > > > One problem with your change is "what binding do we use when we don't want > > > to run code?". The `menu-item' syntax provides a binding (in the example > > > above it's "my-filter" which is not very useful indeed) for the case > > > where code should not be evalled (for example in `where-is'). > > > > Who said we don't want to run code :-) > > The current code says so. But the `cond' is equivalent to (and implemented using) `menu-item', so what's the difference? I know we don't want to run code in current_minor_maps, but that isn't involved here AFAICS. > > > > > It will then be quite trivial to enhance `define-key' to handle > > > > conditional bindings: > > > > > > But is it desirable ? > > > > Don't really know... It seems like a simple approach to allow > > packages to hook into "standard bindings". > > How about a set of examples where the current code does not provide > sufficient flexibility ? I can come up with plenty of examples > where we could use your code, but for most/all of them we could > just as well put the bindings in minor/major-mode-maps or text-property > keymaps. Yes, but then the "general functionality" of `menu-item' isn't needed either? > > The point is that you can install a package - like table.el - which is > > then able to install its own conditional binding on C-y *without* > > interferring with (or even knowning) the standard binding. > > I don't think that's right. I don't believe that table wants to override > C-y sometimes: instead it wants to override `yank' sometimes. > So what you want to do is to create `yank-careful' and then use > either the `remap' thingy or substitute-key-definition or something > like that. Yes, I agree with you. Packages should override commands, not specific bindings. > > Then table.el would still be able to install its own conditional > > binding on C-y. > > Now that's a more interesting example. But maybe that calls for > replacing `yank-careful' with a (defadvice yank ...) or something > like that. I admit that I don't think either of yank-careful or > defadvice are quite satisfactory for this case. > But maybe, using `remap', we could check for an existing `remap' > binding before adding our own, so that table.el would not defer > to `yank' but to `yank-careful'. For that, using the `cond' binding would still be useful I think. E.g. something like this: (define-key global-map [remap yank] 'yank-with-properties '(table-p (car kill-ring))) > > > > The advantage is that C-h k C-y doesn't just give you one of the two > > > bindings but a docstring that describes both. Of course we could also > > > improve C-h k to recognize your `cond' construct, etc... but is it > > > really worth the trouble ? > > > > I didn't think about that, but it would be a nice way to report such > > "multiple" bindings on a key... > > > > But you may also consider this as a different approach than using a > > minor-mode-keymap, and in that case, I think C-h k doesn't report all > > possible bindings for a key -- only the "currently active" binding, so > > why does `cond' have to behave differently? > > It depends on whether the conditional that determines if the binding > is active changes frequently or not (or implicitly or not). Maybe this would be a desired difference between using `cond' and minor mode bindings. `cond' bindings report all possible functions, while minor mode bindings show only the currently active binding. -- Kim F. Storm http://www.cua.dk