From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Drew Adams" Newsgroups: gmane.emacs.devel Subject: RE: propose adding Icicles to Emacs Date: Tue, 3 Jul 2007 00:56:26 -0700 Message-ID: References: NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-15" Content-Transfer-Encoding: 7bit X-Trace: sea.gmane.org 1183449477 16311 80.91.229.12 (3 Jul 2007 07:57:57 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Tue, 3 Jul 2007 07:57:57 +0000 (UTC) Cc: monnier@iro.umontreal.ca, emacs-devel@gnu.org To: Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Jul 03 09:57:55 2007 connect(): Connection refused Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1I5dGj-0004Z8-1T for ged-emacs-devel@m.gmane.org; Tue, 03 Jul 2007 09:57:53 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1I5dGi-0001aU-O4 for ged-emacs-devel@m.gmane.org; Tue, 03 Jul 2007 03:57:52 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1I5dGf-0001Zv-AX for emacs-devel@gnu.org; Tue, 03 Jul 2007 03:57:49 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1I5dGe-0001Zj-PZ for emacs-devel@gnu.org; Tue, 03 Jul 2007 03:57:49 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1I5dGe-0001Zg-Me for emacs-devel@gnu.org; Tue, 03 Jul 2007 03:57:48 -0400 Original-Received: from rgminet01.oracle.com ([148.87.113.118]) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1I5dGc-0002J7-SJ; Tue, 03 Jul 2007 03:57:47 -0400 Original-Received: from rgmgw3.us.oracle.com (rgmgw3.us.oracle.com [138.1.186.112]) by rgminet01.oracle.com (Switch-3.2.4/Switch-3.1.6) with ESMTP id l637vh3n021972; Tue, 3 Jul 2007 01:57:43 -0600 Original-Received: from acsmt351.oracle.com (acsmt351.oracle.com [141.146.40.151]) by rgmgw3.us.oracle.com (Switch-3.2.4/Switch-3.1.7) with ESMTP id l637nXUR018181; Tue, 3 Jul 2007 01:57:42 -0600 Original-Received: from dhcp-amer-csvpn-gw1-141-144-65-51.vpn.oracle.com by acsmt350.oracle.com with ESMTP id 3008010611183449389; Tue, 03 Jul 2007 00:56:29 -0700 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Brightmail-Tracker: AAAAAQAAAAI= X-Brightmail-Tracker: AAAAAQAAAAI= X-Whitelist: TRUE X-Whitelist: TRUE X-detected-kernel: Linux 2.4-2.6 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:74229 Archived-At: > Your approach makes each command definition that uses "!" in > the interactive spec deal with the list (collective) and > non-list (individual) cases together, in a conditional in its > body. > > That's the purpose of `!': so you can distinguish those two cases. > If you don't want to distinguish them, then you don't write `!'. I understand that. And if you want to distinguish them, then you need the conditional, as you indicated. > Then the command gets called once for each argument. Are you saying that if you use `!' in the interactive spec then a user can have only the whole-set-at-once behavior and not also the act-on-each-candidate behavior? I thought we were talking about _adding_ the former, not substituting it for the latter. Now it sounds as if you want to take the latter away. Acting on a set as a whole is different from acting on each of its elements. There is no reason to try to substitute one for the other, instead of providing for both. > I think it is a simple feature that makes it possible to implement, > in a clean way, all the multi-command features that we have discussed. I don't know about that. I haven't heard you confirm or explain how it provides for the actions #1-#4 that I listed (1: help action, 2: main action, 3: alt action, 4: delete action). You've only mentioned the main action (#2) and applying a different action to the list as a whole (#5). And it seems you are saying now that acting on the list (#5) would mean foregoing acting on all matching candidates individually (`C-!'). It's not clear to me what you are saying about the various actions. Another reason I gave for using variables bound to action functions is so that other code can override or test such a binding. For example, one multicommand calls another to implement some of its behavior, but it overrides a default action function or tests whether an action function is defined. I gave an example illustrating the override. > This still assumes your automatic treatment of multicommands via > `call-interactively'. > > Exactly. That's a better method. The "this" was an example that used my approach of binding the set-as-a-whole action function. It was a hybrid example that adopted (assumed) your C-language enhancement to support the use of an argument for a multicommand. > > I think it is a simple feature that makes it possible to implement, > in a clean way, all the multi-command features that we have discussed. Repeating that doesn't show how it is so. You still haven't mentioned how you will you implement/support the various actions (#1-#6). > The way I do it now separates each of the action functions > (the action "implementations", in your terms) from the command > definition itself: > > (defun command () > (interactive) > (let ((candidate-action-fn 'action-one) > (all-candidates-action-fn 'action-all)) > (action-one (read-file-name "File: ")))) > > That's why my method is better. What's why? What's the reason? If a programmer defines a command with each of the actions #1-#6, then, IIUC, you end up with a big conditional in the command body with your approach. Why is that better? > (Note that this example reads a minibuffer argument inside the body of > the command, contrary to Emacs convention, which says you should read > them inside `interactive'.) Do you mean this convention from the Elisp manual (sans rationale BTW)? "In most cases, you should not call minibuffer input functions in the middle of a Lisp function. Instead, do all minibuffer input as part of reading the arguments for a command, in the `interactive' specification." In most cases, OK, but it depends on the context. When input is read inside `interactive' it is done before other processing by the command (unless some such processing is also shoved inside `interactive', before the read, which can result in contrived/unnatural code). That's not always the most appropriate behavior. You can also say that one should, in most cases, read command arguments inside `interactive' (which is not quite the same thing). What is read here is not an argument (or a "minibuffer argument"). You can argue that it should be, that it's better, in most cases, to read user input as arguments. But, as you know, without redefining some of the basic C infrastructure (as you now intend to do), it was not possible to put the multicommand read inside `interactive'. Thus the departure from convention. I gave the hybrid example to show that I agree that it would be good to be able to treat the completion candidate as an argument. Anyway, as I already said: > I'm not against such an approach. I'm just saying that I'm > not yet convinced it is an improvement. Of course, you don't > need to convince me. You don't need to convince me, but I do wonder if/how you intend to support each of the possible actions we've discussed so far: #1-#6, plus letting users apply #2 (main action) and #3 (alt action) to all matching candidates individually.