From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: David Kastrup Newsgroups: gmane.emacs.devel Subject: Re: should read-file-name not respect text properties in its input string? Date: Sun, 22 Jun 2008 09:17:23 +0200 Message-ID: <85tzfm7xbw.fsf@lola.goethe.zz> References: <001c01c8d325$4a595bc0$0200a8c0@us.oracle.com> <003401c8d35b$9a50cb50$0200a8c0@us.oracle.com> <004a01c8d3d7$77c815d0$0200a8c0@us.oracle.com> <005701c8d3f2$d5676a90$0200a8c0@us.oracle.com> <005801c8d415$577953f0$0200a8c0@us.oracle.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1214119060 11799 80.91.229.12 (22 Jun 2008 07:17:40 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 22 Jun 2008 07:17:40 +0000 (UTC) Cc: 'Stefan Monnier' , emacs-devel@gnu.org To: "Drew Adams" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Jun 22 09:18:24 2008 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 1KAJqB-0002K4-VB for ged-emacs-devel@m.gmane.org; Sun, 22 Jun 2008 09:18:24 +0200 Original-Received: from localhost ([127.0.0.1]:54444 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KAJpM-0004mB-Mg for ged-emacs-devel@m.gmane.org; Sun, 22 Jun 2008 03:17:32 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KAJpH-0004kW-E1 for emacs-devel@gnu.org; Sun, 22 Jun 2008 03:17:27 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KAJpG-0004k4-Vn for emacs-devel@gnu.org; Sun, 22 Jun 2008 03:17:27 -0400 Original-Received: from [199.232.76.173] (port=50681 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KAJpG-0004k1-N4 for emacs-devel@gnu.org; Sun, 22 Jun 2008 03:17:26 -0400 Original-Received: from mx20.gnu.org ([199.232.41.8]:50614) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1KAJpG-0007kS-5e for emacs-devel@gnu.org; Sun, 22 Jun 2008 03:17:26 -0400 Original-Received: from mail-in-01.arcor-online.net ([151.189.21.41]) by mx20.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1KAJpF-0001sN-Ff for emacs-devel@gnu.org; Sun, 22 Jun 2008 03:17:25 -0400 Original-Received: from mail-in-18-z2.arcor-online.net (mail-in-18-z2.arcor-online.net [151.189.8.35]) by mail-in-01.arcor-online.net (Postfix) with ESMTP id 24D00104DC1; Sun, 22 Jun 2008 09:17:24 +0200 (CEST) Original-Received: from mail-in-07.arcor-online.net (mail-in-07.arcor-online.net [151.189.21.47]) by mail-in-18-z2.arcor-online.net (Postfix) with ESMTP id 0A1A4510042; Sun, 22 Jun 2008 09:17:24 +0200 (CEST) Original-Received: from lola.goethe.zz (dslb-084-061-005-023.pools.arcor-ip.net [84.61.5.23]) by mail-in-07.arcor-online.net (Postfix) with ESMTP id CFC1B292B65; Sun, 22 Jun 2008 09:17:23 +0200 (CEST) Original-Received: by lola.goethe.zz (Postfix, from userid 1002) id 72E381C2D55B; Sun, 22 Jun 2008 09:17:23 +0200 (CEST) In-Reply-To: <005801c8d415$577953f0$0200a8c0@us.oracle.com> (Drew Adams's message of "Sat, 21 Jun 2008 20:09:10 -0700") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (gnu/linux) X-Virus-Scanned: ClamAV 0.93/7407/Mon Jun 9 04:21:00 2008 on mail-in-07.arcor-online.net X-Virus-Status: Clean X-detected-kernel: by mx20.gnu.org: Linux 2.4-2.6 X-detected-kernel: by monty-python.gnu.org: Linux 2.6, seldom 2.4 (older, 4) 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:99673 Archived-At: "Drew Adams" writes: >> So, if you can come up with >> actual scenarios where those properties could be >> useful/important, maybe >> we can make sure not only that they're returned but that they are >> returned reliably. If you can't come up with such a scenario, that >> casts doubts on the usefulness of the requested change. > > I've no desire to belabor this. I'm not selling anything. If you don't want to > do it, please don't. > > The general argument is that `completing-read' should be lossless; it > should be only about choosing, not losing info. Why? Why not? There is > no reason that it should lose info. > > You agree that it should accept a set of rich structures, display > them, and let you choose from them. Uh, _I_ don't agree. At best, this may be argued for completing-read with neither nil or confirm-only as REQUIRE-MATCH. Other than that, user input can be passed into it that need not match anything in the completion list. Then it does not make sense that sometimes information will be picked from the completions, sometimes not. So what if there text properties in it, and the user input contains different text properties? Is that supposed to be a non-match? Are the user input text properties to be thrown away? Why would you want to throw the user input information rather than the completion information away? > So far so good. Why should what you get back be only a stripped down > string instead of the whole structure you chose, including properties > that might not be visible? It's not only about rich display (color > etc.); it's also about choosing possibly complex objects. It's not > only visible properties that are useful. So why would you throw the properties in the user entry away when they did not come about by completion, but the user input matches a completion candidate? > Using properties lets an application pass along additional information > about a candidate choice, in addition to the string text - not just to > *Completions* but to the `completing-read' caller as the return > value. The info can group/classify candidates, order them, or do > anything else you want. Why would it do that if the information was not entered by completion, but merely matches a completion candidate by chance? > Are there other ways to associate additional info with string > candidates, besides using text properties? Sure, and I use some of > them too. But why not provide this capability? Because no consistent behavior has been proposed so far? > If the general rationale (don't lose info) doesn't convince you, and > the suggestions of uses don't inspire you, fuggedabowdit. So why lose the info from the keyboard entry and replace it with the info of a completion candidate in case there is one? If the completion candidates are not even consulted (like when REQUIRE-MATCH is nil and TAB never is hit), why would I paste over the user's text properties? -- David Kastrup, Kriemhildstr. 15, 44793 Bochum