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 Date: Mon, 25 Jun 2007 08:23:46 -0700 Message-ID: References: NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Trace: sea.gmane.org 1182785167 14195 80.91.229.12 (25 Jun 2007 15:26:07 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Mon, 25 Jun 2007 15:26:07 +0000 (UTC) Cc: rms@gnu.org, emacs-devel@gnu.org To: "Stefan Monnier" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Jun 25 17:26:06 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 1I2qS3-0006pr-EK for ged-emacs-devel@m.gmane.org; Mon, 25 Jun 2007 17:26:03 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1I2qS2-0002mW-Rz for ged-emacs-devel@m.gmane.org; Mon, 25 Jun 2007 11:26:02 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1I2qRe-0002Re-BX for emacs-devel@gnu.org; Mon, 25 Jun 2007 11:25:38 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1I2qRb-0002P3-Sv for emacs-devel@gnu.org; Mon, 25 Jun 2007 11:25:38 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1I2qRb-0002Ow-G6 for emacs-devel@gnu.org; Mon, 25 Jun 2007 11:25:35 -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 1I2qRZ-0007Hl-UK; Mon, 25 Jun 2007 11:25:34 -0400 Original-Received: from rgmgw1.us.oracle.com (rgmgw1.us.oracle.com [138.1.186.110]) by agminet01.oracle.com (Switch-3.2.4/Switch-3.1.7) with ESMTP id l5PFPUQS018372; Mon, 25 Jun 2007 10:25:31 -0500 Original-Received: from acsmt351.oracle.com (acsmt351.oracle.com [141.146.40.151]) by rgmgw1.us.oracle.com (Switch-3.2.4/Switch-3.1.7) with ESMTP id l5PE9JEs020502; Mon, 25 Jun 2007 09:25:29 -0600 Original-Received: from dhcp-amer-csvpn-gw2-141-144-74-244.vpn.oracle.com by acsmt350.oracle.com with ESMTP id 2985025511182785042; Mon, 25 Jun 2007 08:24:02 -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:73828 Archived-At: > > 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. > > Note that it's not nearly as bad as you make it sound: "foo&bar" > does match the string "foo&bar" (as well as a few others). That's not the point. If the aim is to show how the current set of matching candidates was defined (but why?), then that can be done, but it should not be shown in the minibuffer, as if it were a match string. In Icicles, the minibuffer contents are used to match candidates. `foo&bar' as minibuffer input, which matches a certain set of candidates, is different from `foo&bar' as an indication that you happened to define the current set of matches by intersecting the matches of `foo' with the matches of `bar'. `foo&bar' as input to match is different from `foo&bar' as informative(really?) output. Could such output be placed somewhere in the minibuffer, other than where input occurs - as part of the prompt, perhaps, or in a way similar to icomplete annotation? Sure. Should that be done? No, IMO. That info is not helpful. The most important reason is that how you happened to define the set of matching candidates is irrelevant. A set can be defined in many different ways. Whether you chose the candidates one by one, performed a set union, a set complement, a set difference, a set intersection, or some combination of those operations is not important (why would it be?). What is important is the resulting current match set, which you can see in *Completions*. Why also show `foo&bar' or `(foo&bar)|toto' or `(~foo|bar)&(toto - titi)' to indicate which set operations were performed? _If_ you demonstrate that such info could sometimes be relevant, then it should be shown elsewhere (from the minibuffer input area). IMO, all printable characters should be available for editing in the minibuffer and inclusion in minibuffer input. SPC, ?, &, whatever. The TAB key is an exception, because it generally does not just insert the TAB character in Emacs (and I didn't want to disrupt the conventional use of TAB for completion). Likewise for newline (`C-j'). (Actually, I think maybe C-j should also be a normal character for minibuffer input - I'll think about possibly making it so, for Icicles. It's often the case that you need to input C-j in Icicles minibuffer input, to match multiline candidates.) Emacs 22 has finally started to allow SPC in minibuffer input, but only for filenames. Eventually, if Emacs completion becomes more general, as it is in Icicles, I expect that Emacs too will lighten up and let users match SPC, ?, &, etc. (without quoting them with C-q). IMO.