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: Fri, 15 Jun 2007 14:04:49 -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 1181941559 12884 80.91.229.12 (15 Jun 2007 21:05:59 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Fri, 15 Jun 2007 21:05:59 +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 Fri Jun 15 23:05:57 2007 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 1HzIyx-0004ew-Jw for ged-emacs-devel@m.gmane.org; Fri, 15 Jun 2007 23:05:43 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1HzIyx-0004LA-5J for ged-emacs-devel@m.gmane.org; Fri, 15 Jun 2007 17:05:23 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1HzIyu-0004It-4D for emacs-devel@gnu.org; Fri, 15 Jun 2007 17:05:20 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1HzIyt-0004HE-7b for emacs-devel@gnu.org; Fri, 15 Jun 2007 17:05:19 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1HzIyt-0004H3-3O for emacs-devel@gnu.org; Fri, 15 Jun 2007 17:05:19 -0400 Original-Received: from agminet01.oracle.com ([141.146.126.228]) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1HzIyr-0001YY-Cc; Fri, 15 Jun 2007 17:05:17 -0400 Original-Received: from rgmgw2.us.oracle.com (rgmgw2.us.oracle.com [138.1.186.111]) by agminet01.oracle.com (Switch-3.2.4/Switch-3.1.7) with ESMTP id l5FL5Egh007155; Fri, 15 Jun 2007 16:05:14 -0500 Original-Received: from acsmt350.oracle.com (acsmt350.oracle.com [141.146.40.150]) by rgmgw2.us.oracle.com (Switch-3.2.4/Switch-3.1.7) with ESMTP id l5FL5CUm022677; Fri, 15 Jun 2007 15:05:13 -0600 Original-Received: from dhcp-amer-csvpn-gw1-141-144-64-138.vpn.oracle.com by acsmt351.oracle.com with ESMTP id 2920744721181941497; Fri, 15 Jun 2007 14:04:57 -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:73008 Archived-At: > Are you sure that that code cannot be made modular enough to be added, > without breaking the basic design and starting over from scratch? > > I am absolutely sure that my implementation of multi-command behavior > is much cleaner. Replaceing a standard command is undesirable, so I > would like to minimize the number of commands that we need to replace. Which command replacement are we talking about? I already detailed what would be needed for `completing-read' and all of the other functions Icicles that redefines. Those things I mentioned that cannot be foregone would need to be done anyway, irrespective of multi-commands. Apparently I still haven't made myself clear: Icicles replaces no commands. It simply _rebinds_ some keys (and only if a user asks it to). This is about command remapping, which is about key bindings. There is nothing unclean about command remapping. I think you mean to say that your approach would provide some multi-command behavior without the need to define some multi-commands. I agree that that would be a good thing, if that's what you're referring to here by "commands that we need to replace." I just want to be clear that we do _not_ need to replace any commands. _If_ you want `find-file' to act as a multi-command, then, in Icicles, you need to define a multi-command for that. In your approach, IIUC, `find-file' itself (and all commands that use completion in their interactive specs) would automatically be a multi-command. And, as I've said before, that is a good thing: I support your idea, IIUC. > > The only purpose that I know of for defining Icicle-find-file is to > > implement multi-command behavior. Is there any other reason? > > No, that is correct - it is the only reason. > > That's what I thought. Therefore, my approach to multi-command > behavior will eliminate the need for many of Icicle's substitutes for > standard commands. See above. You are phrasing the situation wrong (Icicles does not need to substitute any standard commands), but I have no problem with what I think you're really trying to say (see above). > So I propose two things to be done in parallel: > > * Implement multi-command behavior at the level of Fcall_interactively. > > * Make a version of Icicles that doesn't define Icicle-find-file > and the other simple replacements (which are just for the purpose > of the multi-command feature). Sounds good to me. > #1 is necessary to enable `C-RET', that is, to make it a > multi-command at all. With your implementation of > multi-commands, some such variable would > still be necessary in the general case, to override use of > the command body for the action function - that is, to > provide a different action from what the command itself > performs when you finally choose a candidate once and for > all. > > Can you explain some _specific_ reasons why that is needed? > Becuase it seems to me we can probably do without it. We can do without anything, of course. I already explained this and gave examples. If you want to forego such features and have only a limited form of multi-commands, then that's your decision. I argued for adopting your implementation approach but also letting people bind the 4 kinds of actions around any calls to completion functions (e.g. `completing-read'): 1) action, 2) alternative action, 3) deletion, 4) candidate help. IIUC, your implementation limits a multi-command to using completion in the `interactive' spec, and (so far), it does not let you provide specific functions for the 4 possible multi-command actions. > One use case is defining a command that is itself called when defining > another command. The first command might define a default > action function if `icicle-candidate-action-fn' is nil when it is > called. The second command can bind the action function to > override the default in the command it calls. (There was an > example of this, but I no longer have one to point to.) > > That is rather abstract and I find I just can't follow it. `icicle-search' provides for this, but there is today no command defined using `icicle-search' that takes advantage of it. This is what `icicle search' does: (let ((icicle-candidate-action-fn (or icicle-candidate-action-fn 'icicle-search-action)) (icicle-candidate-help-fn 'icicle-search-help) (icicle-update-input-hook (list 'icicle-search-highlight-all-input-matches))) The binding of `icicle-candidate-action-fn' here lets a caller of `icicle-search' bind its own action function, to override the default one, `icicle-search-action'. There was a command that did that previously, but there is none currently. You can also see here an example of binding a candidate-help function that is specific to this command (`icicle-search'). Icicles provides help on individual candidates you choose (e.g. with `C-M-RET'), and a default help function does that. It works quite well for lots of kinds of candidates, but you might want, in your command, to define a specialized help function - that's what `icicle-search' does: `icicle-search-help'. > 2. `icicle-candidate-alternative-action-fn' - an alternative > action function > 3. `icicle-delete-candidate-object' - a deletion action And I forgot to list: 4. `icicle-candidate-help-fn' - a candidate help function. > The easiest way to handle these is to use properties of the > command symbol, `minibuffer-alt-action', `minibuffer-delete-action'. > So we could do > > (put 'find-file 'minibuffer-delete-action 'delete-file) > > S-delete would be defined to look for that property on this-command > to decide what to do. > > We could implement the equivalent of `icicle-candidate-action-fn' > easily in the same way. Yes, that works too. I considered that, but I decided that binding was more flexible, allowing more control over scope (overriding etc.).