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: Wed, 13 Jun 2007 12:22:44 -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 1181752003 17034 80.91.229.12 (13 Jun 2007 16:26:43 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Wed, 13 Jun 2007 16:26:43 +0000 (UTC) Cc: emacs-devel@gnu.org To: "Drew Adams" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Jun 13 18:26:42 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 1HyVg3-00033G-FS for ged-emacs-devel@m.gmane.org; Wed, 13 Jun 2007 18:26:35 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1HyVg2-0003og-UZ for ged-emacs-devel@m.gmane.org; Wed, 13 Jun 2007 12:26:34 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1HyVcM-0002Ii-ST for emacs-devel@gnu.org; Wed, 13 Jun 2007 12:22:46 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1HyVcM-0002IG-AX for emacs-devel@gnu.org; Wed, 13 Jun 2007 12:22:46 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1HyVcL-0002IA-Q8 for emacs-devel@gnu.org; Wed, 13 Jun 2007 12:22:45 -0400 Original-Received: from fencepost.gnu.org ([140.186.70.10]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1HyVcL-0003zT-7X for emacs-devel@gnu.org; Wed, 13 Jun 2007 12:22:45 -0400 Original-Received: from rms by fencepost.gnu.org with local (Exim 4.60) (envelope-from ) id 1HyVcK-0001gD-IQ; Wed, 13 Jun 2007 12:22:44 -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:72777 Archived-At: I'd propose adding Icicles first as an optional library, without trying to integrate any of it deeply with Emacs. Later, we could look into a possible tighter integration. That is a very bad idea. "Temporary" solutions tend to become permanent, and to prevent that from occurring requires insistence. No software developer should install code meant to be temporary unless it is essential to do so. Icicles features are nice, but installing them is not essential. Therefore we will put the code into the form we want to keep permanently and then install it. > Why does it do this? Because those replacements are enhanced versions. They are typically multi-commands that 1) keep the same behavior as the original, as long as you don't use any special Icicles minibuffer bindings, but also 2) let you take advantage of those minibuffer bindings (e.g. `C-RET') to get the multi-command behavior. Let's suppose I can magically implement multi-command behavior without the need to define separate multi-commands to do it. (I think I can, and I explained how.) Is there any other reason in icicles to define new commands to replace the existing ones? If so, what is it? Maybe I can find a better way to implement that, too. The need to replace commands is a complexity, and the code will be much better if we avoid that complexity. Yes, you must define a new command, in order to adapt a given existing command to multi-command use. This is a good thing, as some commands might not lend themselves well to multi-command use (i.e. it might make no sense for them, adding nothing). That is no argument against making multi-command behavior magic. Just respond, "If it isn't useful there, don't use it there." And, more often, it is appropriate for some commands to have a slightly different action function for candidates during completion than after completion (for instance, because the buffer/window/frame context or the use context might be different). This might be a real issue. Can you please give an example or two? If Icicles does not break anything, and it does not have a lasting effect when you leave Icicle mode, then I think how it is implemented should not be a concern. That is true if you distribute it separately. If it is part of Emacs, that changes everything. We want Emacs to be modular. My proposed implememtation of multi-command behavior is totally modular. I think we can make it work with NO changes in any specific command. The macro expansion of a multi-command defined using #1 or #2 is quite complex. Some of its definition implements context management (window, frame, buffer), and some of it implements treatment of possible errors from application of the action function. For example, the original buffer, window, or frame, to which we often want to return, might have been deleted by application of the action to a particular candidate (e.g. if the action is to kill the buffer, and the candidate acted on is the original buffer). And we usually want to keep the focus after action application on the minibuffer's frame, so that we can possibly keep using `C-RET' etc. on other candidates. The code in call-interactively may need to deal with such cases. I think it can do so in ways that are independent of the specific command that was run. Wrt prefix args: C-u is treated specially during completion, so that, for instance, you can apply it to individual candidates that you act on using `C-RET'. That is, you can use a different prefix argument each time you act on a candidate, if you like. I just assumed it was the other way. We could handle the prefix this way just as easily. Remember, that, by default, you can act on the same candidate multiple times. Sometimes that makes sense, sometimes it does not. Can you give me an example where it does not make sense? 2. It's appropriate, for many commands, to specialize the action behavior during completion. See the commands that explicitly bind `icicle-candidate-action-fn', as opposed to just using `icicle-define-command'. Command `icicle-search', for instance, could not be defined using `icicle-define-command'. Can you please explain an example of this specialization? Then I can think about its consequences.