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: Mon, 25 Jun 2007 14:40:48 -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 1182807724 6863 80.91.229.12 (25 Jun 2007 21:42:04 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Mon, 25 Jun 2007 21:42:04 +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 Mon Jun 25 23:42:02 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 1I2wJt-00086c-N8 for ged-emacs-devel@m.gmane.org; Mon, 25 Jun 2007 23:42:01 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1I2wJt-0002T3-9d for ged-emacs-devel@m.gmane.org; Mon, 25 Jun 2007 17:42:01 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1I2wJq-0002SF-5m for emacs-devel@gnu.org; Mon, 25 Jun 2007 17:41:58 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1I2wJo-0002S1-Kk for emacs-devel@gnu.org; Mon, 25 Jun 2007 17:41:56 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1I2wJo-0002Ry-Ez for emacs-devel@gnu.org; Mon, 25 Jun 2007 17:41:56 -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 1I2wJm-0000CB-QG; Mon, 25 Jun 2007 17:41:55 -0400 Original-Received: from rgmgw2.us.oracle.com (rgmgw2.us.oracle.com [138.1.186.111]) by rgminet01.oracle.com (Switch-3.2.4/Switch-3.1.6) with ESMTP id l5PLfqxM001910; Mon, 25 Jun 2007 15:41:52 -0600 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 l5PKao3i017057; Mon, 25 Jun 2007 15:41:51 -0600 Original-Received: from dhcp-4op11-4op12-west-130-35-178-179.us.oracle.com by acsmt351.oracle.com with ESMTP id 2986973971182807649; Mon, 25 Jun 2007 14:40:49 -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-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:73868 Archived-At: > > But this suggests there should be a minibuffer command to > > say "submit each of current candidates, one by one." > > What do you mean, "submit"? Submit to what? > > Submit as an argument. Just as C-RET submits the current minibuffer > contents as an argument (then reads another), this proposed command > would submit EACH of the current contents, one by one. To be clear: C-RET applies the action function to the current candidate as an argument, but it does not read another. It does not end completion, so you simply type (or cycle to) another candidate - there is no read operation. C-! already applies the action function to EACH of the candidates that currently match the minibuffer contents, one by one. Is that what you meant? In the case of `customize-face', that opens a separate Customize buffer for each chosen face. If you instead mean to apply some function to a list of ALL of the candidates, then see my previous message. For that, you would use a function (a multi-command, in fact) that lets the user choose a list of candidates and returns that list, and then you would act on the list. In the case of a command `customize-faces', it would use multicommand `icicle-face-list' to query the user for the list of faces, and then it would call `custom-buffer-create' on `custom-sort-items' of the list of faces - exactly as does `customize-apropos' today. For examples of commands that use a multicommand that returns a list of candidates that the user has chosen, see these commands: icicle-add-buffer-config, icicle-search, icicle-occur, icicle-search-char-property, icicle-search-file, and icicle-search-keywords. Each of these uses a function (a multi-command) that asks the user to pick a list of candidates (of files, buffers, faces, keywords, etc.), and then it does something with that list. For example, `icicle-search-keywords' lets the user pick keywords (regexps, actually), and then it searches for any combination of those keywords. That is, it creates a choice regexp (\(...\|...\|...\)) from the keywords, and then it searches for that. The function that queries the user for the list of keywords is the multi-command `icicle-keyword-list', but the user does not call this directly, here. If you were proposing to add a binding during completion that would always do this kind of thing, then, yes, that could be attempted (I've considered it, but I haven't done it yet). However, the function invoked on that list needs to be supplied somehow - it cannot be the same function as C-RET (that is what C-! does already). In the case of customizing faces, for instance, that function would need to do what `custom-apropos' does with the list. The way I would do that is to have another variable, similar to `icicle-candidate-action-fn' and `icicle-candidate-alternative-action-fn', that could be bound by the command. I would call it `icicle-all-candidates-action-fn'. It would perform the action to which it is bound on the list of chosen candidates. In the case of `customize-face', for instance, this would then be the definition: (defun icicle-customize-face (face) "Customize face FACE." (interactive (list (let ((icicle-candidate-action-fn 'customize-face) (icicle-all-candidates-action-fn 'customize-faces)) (read-face-name "Customize face: ")))) (customize-face face)) Where `customize-faces' would be defined something like this: (defun customize-faces (faces) "Open Customize buffer on all faces in list FACES." (custom-buffer-create (custom-sort-items faces t custom-buffer-order-groups) "*Customize Apropos*"))) Any way you look at it, I think you need to define the function that acts on the list of chosen candidates. It cannot be defined automatically from the `C-RET' action function - at least not in the general case.