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, 26 Jun 2007 10:36:07 -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 1182879468 3038 80.91.229.12 (26 Jun 2007 17:37:48 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Tue, 26 Jun 2007 17:37:48 +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 Jun 26 19:37:45 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 1I3Ez1-00029S-F8 for ged-emacs-devel@m.gmane.org; Tue, 26 Jun 2007 19:37:43 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1I3Ez1-0001o8-8I for ged-emacs-devel@m.gmane.org; Tue, 26 Jun 2007 13:37:43 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1I3Eyy-0001nn-4d for emacs-devel@gnu.org; Tue, 26 Jun 2007 13:37:40 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1I3Eyx-0001nY-Fi for emacs-devel@gnu.org; Tue, 26 Jun 2007 13:37:39 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1I3Eyx-0001nV-Bo for emacs-devel@gnu.org; Tue, 26 Jun 2007 13:37:39 -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 1I3Eyu-0006M9-Db; Tue, 26 Jun 2007 13:37:36 -0400 Original-Received: from rgmgw3.us.oracle.com (rgmgw3.us.oracle.com [138.1.186.112]) by agminet01.oracle.com (Switch-3.2.4/Switch-3.1.7) with ESMTP id l5QHbXOV009880; Tue, 26 Jun 2007 12:37:33 -0500 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 l5QGOwog008880; Tue, 26 Jun 2007 11:37:27 -0600 Original-Received: from dhcp-amer-rmdc-csvpn-gw4-141-144-97-223.vpn.oracle.com by acsmt350.oracle.com with ESMTP id 2989195951182879370; Tue, 26 Jun 2007 10:36:10 -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.3138 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:73883 Archived-At: > C-! already applies the action function to EACH of the candidates that > currently match the minibuffer contents, one by one. > > It sounds like that is the same feature. That is good. > > In the case of `customize-face', that opens a separate > Customize buffer for each chosen face. > > I think `customize-face' as a multi-command should put all the faces > in one Custom buffer. (Likewise the other `customize-...' commands.) Then it needs to be defined that way. The point is that `C-!' simply applies the action function (i.e. what `C-RET' does) to each candidate, in turn. If that action function is the current `customize-face', then it opens a new Customize buffer - for that candidate. Opening a new Customize buffer is part of the current definition of `customize-face'. If the same function is used to act on a single candidate and to act on all matching candidates, then you can get into trouble. The candidate action function takes a candidate and does something with it. You are talking about a function that takes a list of candidates and does something with that list. That is not the same function. If a given action function had an arg list such as (&rest candidates), then you might be able to apply it to both a single candidate and multiple candidates. But in the general case, you don't have control over what the supplied action function is. You can try to build in such a treatment, if you forego the ability of a programmer to specify a different action function. If you try to automatically convert each command that takes a candidate as arg into a multicommand that operates on a list of such args, then you can do what you hint (IIUYC). But you still need to provide the ability to do both: act on all matching candidates individually (what C-! does) and act on all matching candidates together. You still need to let the user do either of those. IMO, it would be best to let the programmer define those actions separately, instead of coupling them in some automatic way. IMO, the way to handle this is what I said in my previous mail: bind a function that expects and treats a list of candidates - `icicle-all-candidates-action-fn'. That function can do whatever it wants. In the case of `customize-face', it would open a single buffer for all matching candidates, whereas `icicle-candidate-action-fn' opens a buffer for its single candidate. Opening a buffer is obviously only one possibility of a difference between a desired action on the set as a whole and the set of desired actions on each of the set members. The point is that if a programmer wants such a difference in behavior in a particular case, then s?he needs to specify it (unless you prohibit that expression and you impose a predefined relation). A good way to specify those two different behaviors is by providing two different functions. Anyway, it's almost impossible to discuss this, because you are not specific about your approach. We are waving at each other over a great distance, making inordinate efforts to guess what the other is signaling. If you don't want to talk about the details of the Icicles design and implementation, then you need to provide the details of the design and implementation that you have in mind. Otherwise, this discussion is too abstract to be useful - we cannot follow each other and contribute anything meaningful.