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: Wed, 13 Jun 2007 08:23:30 -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 1181748310 1372 80.91.229.12 (13 Jun 2007 15:25:10 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Wed, 13 Jun 2007 15:25:10 +0000 (UTC) Cc: emacs-devel@gnu.org To: , "Stefan Monnier" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Jun 13 17:25:08 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 1HyUiX-0004Be-Vm for ged-emacs-devel@m.gmane.org; Wed, 13 Jun 2007 17:25:06 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1HyUiX-0006v6-9o for ged-emacs-devel@m.gmane.org; Wed, 13 Jun 2007 11:25:05 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1HyUiT-0006v1-LV for emacs-devel@gnu.org; Wed, 13 Jun 2007 11:25:01 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1HyUiS-0006up-40 for emacs-devel@gnu.org; Wed, 13 Jun 2007 11:25:00 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1HyUiR-0006um-Uh for emacs-devel@gnu.org; Wed, 13 Jun 2007 11:24:59 -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 1HyUiQ-0004XF-1b; Wed, 13 Jun 2007 11:24:58 -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 l5DFOtD7011949; Wed, 13 Jun 2007 09:24:55 -0600 Original-Received: from acsmt350.oracle.com (acsmt350.oracle.com [141.146.40.150]) by rgmgw3.us.oracle.com (Switch-3.2.4/Switch-3.1.7) with ESMTP id l5DCkPtK007925; Wed, 13 Jun 2007 09:24:54 -0600 Original-Received: from dhcp-amer-csvpn-gw2-141-144-74-122.vpn.oracle.com by acsmt350.oracle.com with ESMTP id 2893635221181748218; Wed, 13 Jun 2007 08:23:38 -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: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Importance: Normal X-Whitelist: TRUE X-Whitelist: TRUE X-Brightmail-Tracker: AAAAAQAAAAI= 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:72766 Archived-At: > I think it would be good to include Icicles in Emacs. > Clearly, we wouldn't want to enable it by default since it changes the > behavior too much for many people's tastes, but just like > iswitchb and ido I think it's a valuable extension. > > It sounds like Icicles contains many good features that should be > installed. Perhaps all of them. But we should not keep them as a > bundle simply because they are offered to us as a bundle. We > should separate them if they make more sense separately, and keep > them unified if they make more sense unified. Fine as a generalization. I don't disagree with the logic, including the "simply because", "if", and "if". Where do we go from here? Let me be clear about my position. I see two possibilities, A and B. I prefer A, but I can also live with B. Plan A - My suggestion is to proceed in two stages: 1) take Icicles (i.e. add it to Emacs) as a bundle now, offering it to general Emacs users as a separate, optional package with its current functionality and design, and 2) later, examine parts of Icicles that might usefully be peeled off and added to vanilla Emacs itself, starting with the low-hanging fruit that doesn't shake the entire tree (either Emacs or Icicles). There is no reason that Icicles and Emacs cannot live together as each is now, even if there might be some potential to make each even better by some careful simplification, merging, or whatever in the future. For stage #1, the immediate process of package addition and the period of cohabitation that I propose, I am willing to do some minor cleanup, _if_ it is clear to me what is required and _if_ it doesn't jeopardize the correct functioning of Icicles. I'll consider such changes on a case by case basis, and only _if_ someone works with me to make clear what is needed. I strongly suggest that we make only minimal changes that are truly needed to added Icicles as a separate package (stage #1). Plan B - An alternative (to my two-stage proposal, plan A), which I do not prefer but which could also be workable for me, is for you not to add Icicles to Emacs, but to instead take some of its ideas and add them in your own manner to Emacs. That too works for me. In that case, I'll keep Icicles, and you can borrow ideas from it if you like. That way, you will be clear and content about what you get and how you implement it, and I won't have the discomfort about not understanding what you want changed, or the risk of breaking something because you've asked for changes that are not sufficiently thought out. I will of course be available to answer questions about the existing Icicles features and their implementation. And you can take pieces of existing Icicles code, if you like. _You_ can take - I won't be chopping up Icicles in this scenario. I would prefer plan A - to let general Emacs users take advantage now of all of Icicles, as they do Ido and Iswitchb, to experiment with it, provide feedback on how its parts fit well together or don't, etc. But if you prefer plan B, to treat Icicles only as a quarry of ideas, taking some ideas here and there or not, that's OK by me too. I will continue to develop Icicles separately, and if a piece of it ultimately becomes superfluous because Emacs has implemented something similar, I can then remove it from Icicles. Plan B admittedly has the advantage of going beyond the throw-away prototype, doing things better the second time around. If you choose plan B, I would ask only that you try to proceed in a way that will not make it difficult for people to use Icicles with Emacs in the meantime. For example, if you start adding a different kind of multi-command functionality, please do so in a way that won't conflict too much with using Icicles. That might not be easy or obvious, but if we work together and stay mutually informed, things could be worked out. I'm not demanding that you don't break anything for Icicles - I'm only asking for consideration and cooperation. For now, Emacs does not do much with the minibuffer and Icicles does a lot. Icicles uses lots of new minibuffer bindings, for instance. If Emacs starts using lots of minibuffer bindings that conflict, then let's agree to try to work something out. I'm offering Emacs the ideas of Icicles - and the design and implementation too, if you want it. I hope you can offer cooperation in return. I'd like to see, in order of preference: either (plan A) Icicles working inside Emacs or (plan B) Icicles working outside Emacs (in the sense that it is now "outside"). I don't want to see Icicles no longer working anywhere because it has been dismembered beyond use within Emacs or because Emacs has built up its own features that prevent it from working. > At least one should be implemented differently: multi-commands. > I explained how it is possible to simplify this tremendously > if you don't insist on doing the work at the Lisp level. You explained no such thing. You asked "how does it know what to call?", "is it the same command?", etc. You asked if every command couldn't be automatically converted to a multi-command. I responded to all of this in detail - you have not replied to any of that. You rather cavalierly proposed a different implementation of a feature whose description you were not yet clear about and were therefore still asking about. I explained more about the feature, and I asked you for more detail about your vague redesign - no reply. I explained that I don't want to redesign or to reimplement the basic design. I said that if others wish to do that, later (phase #2 of plan A), then that's another matter. I recommend plan A: leaving the basic design and implementation as they are now, adding the package now, possibly with some minor modifications to fit standards or preferences, and then, perhaps, revisiting design and implementation questions bit by bit later. Once Icicles has been added to Emacs (plan A), IIUC, there are two possibilities: (1) I continue to maintain it for Emacs (within Emacs), or (2) someone else does that. I would prefer to maintain it myself, as I intend to do so anyway, for my own version. However, if Emacs developers want to rework the code extensibly, then that is possible - after Icicles belongs to FSF, and at that point my participation in the maintenance might diminish or dry up altogether. I have nothing against performing some of the functionality in C, for instance, but I will not work on that C code myself (you will be glad of that!). Once you own it, you can break it as you like (to twist the Pottery Barn aphorism a bit). If someone wants to seriously take a look at reworking parts of the package, I'm willing to spend some time working with that person or persons. But I will not take some vague directive to go off and redo things, and then come back to you hoping that things might have been understood and reworked to your satisfaction. I don't read minds, among other things. In sum, either you do it or I do it, and if I do it then I need to understand precisely what "it" is, and I want to agree that "it" really should be done. I am not saying "take it as is or leave it". I'm proposing a couple of different ways you can take it. I'm saying that if there are changes you think should be made, then let's discuss them _in detail_ first. And I'm strongly recommending not to touch the basic structure of the code - at least not for a while. Let users use it as it was intended, and let its evolution and improvement be gradual, informed, and _deliberate_. > I don't know all the features in Icicles. Perhaps other such > simplifications are possible, or perhaps not. Someone needs to check. Someone needs to take it seriously, one way or the other. Not knowing all of the features is OK at this point, but it is not OK to redesign without knowing all of the features and how they work together. (But you have the option of plan B.) I'll consider concrete suggestions of any nature, but I will be reluctant to slash willy nilly and reconstruct. I've said it before; it should be quite clear now. It won't happen on my watch, and without me understanding what it is.