From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Richard Stallman Newsgroups: gmane.emacs.devel Subject: Re: propose adding Icicles to Emacs Date: Fri, 15 Jun 2007 15:22:02 -0400 Message-ID: References: Reply-To: rms@gnu.org NNTP-Posting-Host: lo.gmane.org Content-Type: text/plain; charset=ISO-8859-15 X-Trace: sea.gmane.org 1181935563 25157 80.91.229.12 (15 Jun 2007 19:26:03 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Fri, 15 Jun 2007 19:26:03 +0000 (UTC) Cc: monnier@iro.umontreal.ca, emacs-devel@gnu.org To: "Drew Adams" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Jun 15 21:25:58 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 1HzHQg-00016X-JY for ged-emacs-devel@m.gmane.org; Fri, 15 Jun 2007 21:25:54 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1HzHQg-0001uC-1C for ged-emacs-devel@m.gmane.org; Fri, 15 Jun 2007 15:25:54 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1HzHMx-00084P-J1 for emacs-devel@gnu.org; Fri, 15 Jun 2007 15:22:03 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1HzHMw-000847-UV for emacs-devel@gnu.org; Fri, 15 Jun 2007 15:22:03 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1HzHMw-00083y-LL for emacs-devel@gnu.org; Fri, 15 Jun 2007 15:22:02 -0400 Original-Received: from fencepost.gnu.org ([140.186.70.10]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1HzHMw-0003eK-AV for emacs-devel@gnu.org; Fri, 15 Jun 2007 15:22:02 -0400 Original-Received: from rms by fencepost.gnu.org with local (Exim 4.60) (envelope-from ) id 1HzHMw-0002gK-29; Fri, 15 Jun 2007 15:22:02 -0400 In-reply-to: X-detected-kernel: Linux 2.6, seldom 2.4 (older, 4) 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:72994 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. > 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. 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). #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. 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. 2. `icicle-candidate-alternative-action-fn' - an alternative action function 3. `icicle-delete-candidate-object' - a deletion action 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.