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: Icicles doc - file 1/2 (was: propose adding Icicles to Emacs) Date: Sun, 24 Jun 2007 20:00:00 -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 1182740519 3203 80.91.229.12 (25 Jun 2007 03:01:59 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Mon, 25 Jun 2007 03:01:59 +0000 (UTC) Cc: emacs-devel@gnu.org To: Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Jun 25 05:01:58 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 1I2epv-0002r4-1k for ged-emacs-devel@m.gmane.org; Mon, 25 Jun 2007 05:01:55 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1I2epu-00068H-Mn for ged-emacs-devel@m.gmane.org; Sun, 24 Jun 2007 23:01:54 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1I2epq-00067T-EH for emacs-devel@gnu.org; Sun, 24 Jun 2007 23:01:50 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1I2epo-000670-NX for emacs-devel@gnu.org; Sun, 24 Jun 2007 23:01:50 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1I2epo-00066q-9j for emacs-devel@gnu.org; Sun, 24 Jun 2007 23:01:48 -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 1I2epk-0002dp-Tx; Sun, 24 Jun 2007 23:01:45 -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 l5P31O9e000786; Sun, 24 Jun 2007 21:01:24 -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 l5P31OKM022366; Sun, 24 Jun 2007 21:01:24 -0600 Original-Received: from dhcp-amer-csvpn-gw2-141-144-73-10.vpn.oracle.com by acsmt350.oracle.com with ESMTP id 2983440871182740414; Sun, 24 Jun 2007 20:00:14 -0700 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Brightmail-Tracker: AAAAAQAAAAI= X-Brightmail-Tracker: AAAAAQAAAAI= X-Whitelist: TRUE X-Whitelist: TRUE 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:73789 Archived-At: > > ;; C-h f c h a r S-TAB - display all function names that > > ;; contain `char'. > > ;; > > ;; M-* d e l e t e - narrow that set of names to those > > ;; that also contain `delete'. > > > > I wonder if it would be more convenient to interpret > > some syntax for this, such as `char&delete'. > > I don't think so, but perhaps I don't fully see what you're > proposing. You can type `char S-SPC delete' to do the same > thing. A priori, I am against using printable characters such > as `&' for this kind of thing. > > I think it would be more convenient to use `char&delete' > because that way the minibuffer contents would SHOW the search criterion. I won't use `&' in the version of Icicles that I maintain outside Emacs, but you can use it if you decide to include this Icicles feature in Emacs. FWIW, I recommend that you let users use `&' as a normal character for editing in the minibuffer. In Icicles, minibuffer input can be used for anything and everything - it's not just about file names, buffer names, command names, and variable names anymore. Every printable character will be something that you want to include in minibuffer input sooner or later. And it would be a big mistake (IMO) to make users remember a list of characters that you need to apply `C-q' to in the minibuffer. FWIW, I think that if you use Icicles a bit, you'll see that there is no need to "SHOW the search criteria". The one, basic Icicles feature that all users pick up right away and use all the time thereafter is this one, which I call "progressive completion". There really is no need to see the accumulated set-operation expression (e.g. char & delete, where & means intersect). Instead, users see the set itself as it is shaped, and they think directly in terms of it. Being interactive, it is easy to manipulate and redo things, if you get the wrong expression at some point and thus end up with a candidate set that you didn't expect. FWIW2 - If it was nevertheless felt that users should be able to see a breadcrumbs trace of the candidate-set operations they have performed so far, then the place to show that is in another buffer, as a clear, formatted display - not in the minibuffer as part of the user's input. IMO. > I avoid wasting normal editing keys and printable-character > keys in the minibuffer. In Icicles, for instance, `?' is > simply self-inserting (always) - it is `C-?' that brings up > Icicles help. > > I do not want to remove the minibuffer's binding of `?'. > Adding one new feature is not a reason to delete another old feature. Same answer as for `&'. In Icicles outside Emacs, I'll keep `?' as a normal, self-inserting character for minibuffer editing. You can use whatever you prefer for any Icicles features you adapt for inclusion in Emacs. Again, Icicles uses completion a lot more than vanilla Emacs - for more things in more contexts. There is no reason not to let users use keys such as `&' and `?' (without escaping/quoting) in ordinary minibuffer editing, i.e. in minibuffer input. > Icicles makes many different changes which are logically independent, > and each one needs to be judged separately. Fine. I already stated the same thing. I said that many of the features are not strictly logically interdependent, even when (I think) they belong together because they complement each other and work well together. Please judge them separately for possible adapted inclusion in Emacs as you see fit.