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 07:57:06 -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 1182783578 7088 80.91.229.12 (25 Jun 2007 14:59:38 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Mon, 25 Jun 2007 14:59:38 +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 16:59:35 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 1I2q2N-0000MZ-5q for ged-emacs-devel@m.gmane.org; Mon, 25 Jun 2007 16:59:31 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1I2q2M-00064Q-QP for ged-emacs-devel@m.gmane.org; Mon, 25 Jun 2007 10:59:30 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1I2q20-0005l1-H2 for emacs-devel@gnu.org; Mon, 25 Jun 2007 10:59:08 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1I2q1z-0005kP-UZ for emacs-devel@gnu.org; Mon, 25 Jun 2007 10:59:08 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1I2q1z-0005kL-Pw for emacs-devel@gnu.org; Mon, 25 Jun 2007 10:59:07 -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 1I2q1w-0002fS-Ri; Mon, 25 Jun 2007 10:59:06 -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 l5PEx2rg029097; Mon, 25 Jun 2007 08:59:02 -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 l5PEeaiq006256; Mon, 25 Jun 2007 08:59:01 -0600 Original-Received: from dhcp-amer-csvpn-gw2-141-144-74-244.vpn.oracle.com by acsmt350.oracle.com with ESMTP id 2985003951182783443; Mon, 25 Jun 2007 07:57:23 -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:73826 Archived-At: > I might add that once you have the ability to type and change > the regexp to match dynamically, there is less raison d'etre for these > `customize-apropos-*' commands. An Icicles user would simply use > `customize-face' and so on, instead. > > With `customize-apropos-faces', you get a custom buffer with ALL the > faces whose names match the regexp. Yes, I pointed that out several times as a definite advantage. I said this: >> The only disadvantage is that you cannot use this command to >> customize all matching faces in the same Customize buffer - >> you get a different Customize buffer for each face. On the >> other hand, two advantages are that (1) the >> display of matching faces can be WYSIWYG (because it uses >> `read-face-name') - a much better preview, and (2) you can get >> help about individual faces while you are choosing them, in >> case you have a doubt about the meanings (uses) of some of them. > Using `customize-face' as a multi-command, and regexp-based > completion, you can pick some of the matching faces and put each > of them into a custom buffer. But you can't make a custom buffer > with two of them, or all of them. (Am I mistaken?) That is correct, assuming no changes to `customize-face'. > This suggests that `customize-face', when it uses the multi-command > feature, should put all the faces in one buffer. Well, I think that > is not too hard to do, in my proposed framework. > > 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? Don't forget that there is `C-S-RET' etc., which apply an alternative action. That action could be to collect chosen candidates. IMO, it is useful to be able to have a different final action (`RET') from the intermediate actions (`C-RET'). The final action here could be to act on all in the same Customize buffer. The intermediate action could be to accumulate. As I said in a different message, Icicles has an idiom for this. There are several multicommands that simply return a list of the candidates you choose. Other commands use those commands (e.g. in their `interactive' specs) to determine the user's choices, and then they act on that list as a whole. For instance, multicommand `icicle-face-list' lets you pick a list of faces; it returns the list. A command `customize-face-bis' could use that to define the list of faces to customize, then show Customize for all together. IOW, `C-RET' can be used for multiple choice, and the choices can be acted on together, instead of individually. It all depends on how you define the command. Also, with the save-this-candidate and save-matching-candidates features, you can create a set of candidates you want to act on, verify that set, and then act on it. That action can be either act on each individually or act on all together, depending on how you define the command.