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: should read-file-name not respect text properties in its input string? Date: Sat, 21 Jun 2008 16:02:09 -0700 Message-ID: <005701c8d3f2$d5676a90$0200a8c0@us.oracle.com> References: <001c01c8d325$4a595bc0$0200a8c0@us.oracle.com><003401c8d35b$9a50cb50$0200a8c0@us.oracle.com><004a01c8d3d7$77c815d0$0200a8c0@us.oracle.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1214089394 21989 80.91.229.12 (21 Jun 2008 23:03:14 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 21 Jun 2008 23:03:14 +0000 (UTC) Cc: emacs-devel@gnu.org To: "'Stefan Monnier'" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Jun 22 01:03:59 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 1KAC7i-0007jJ-C5 for ged-emacs-devel@m.gmane.org; Sun, 22 Jun 2008 01:03:58 +0200 Original-Received: from localhost ([127.0.0.1]:52235 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KAC6t-0005cT-DP for ged-emacs-devel@m.gmane.org; Sat, 21 Jun 2008 19:03:07 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KAC6H-00050t-AV for emacs-devel@gnu.org; Sat, 21 Jun 2008 19:02:29 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KAC6F-0004ya-49 for emacs-devel@gnu.org; Sat, 21 Jun 2008 19:02:27 -0400 Original-Received: from [199.232.76.173] (port=59362 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KAC6E-0004yA-IN for emacs-devel@gnu.org; Sat, 21 Jun 2008 19:02:26 -0400 Original-Received: from agminet01.oracle.com ([141.146.126.228]:55387) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1KAC6D-000058-UK for emacs-devel@gnu.org; Sat, 21 Jun 2008 19:02:26 -0400 Original-Received: from agmgw1.us.oracle.com (agmgw1.us.oracle.com [152.68.180.212]) by agminet01.oracle.com (Switch-3.2.4/Switch-3.1.7) with ESMTP id m5LN2NHe008320; Sat, 21 Jun 2008 18:02:23 -0500 Original-Received: from acsmt350.oracle.com (acsmt350.oracle.com [141.146.40.150]) by agmgw1.us.oracle.com (Switch-3.2.0/Switch-3.2.0) with ESMTP id m5LN2MOR030436; Sat, 21 Jun 2008 17:02:22 -0600 Original-Received: from inet-141-146-46-1.oracle.com by acsmt351.oracle.com with ESMTP id 3696735691214089323; Sat, 21 Jun 2008 16:02:03 -0700 Original-Received: from dradamslap1 (/24.5.171.3) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sat, 21 Jun 2008 16:02:03 -0700 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: Thread-Index: AcjT6CI3JBFj46lkRSSJrbz38yywxwAAmEZw X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Brightmail-Tracker: AAAAAQAAAAI= X-Brightmail-Tracker: AAAAAQAAAAI= X-Whitelist: TRUE X-Whitelist: TRUE X-detected-kernel: by monty-python.gnu.org: 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:99648 Archived-At: > So, again, what kind of properties would these be? Uh, again, text properties. Period. Here's one mail from the 2007 thread, which lists possible uses of a few properties: http://lists.gnu.org/archive/html/emacs-devel/2007-01/msg00807.html However, a priori, any text properties at all. An application might add its own, original properties and treat them in different ways. Properties can even distinguish candidates that otherwise have the same string (Icicles uses this possibility in some contexts). There are lots of possible uses - use your imagination. It's easy enough for a caller to strip properties. And it's easy enough for a caller to strip completion candidates of properties from the outset. No reason for `completing-read' to systematically strip properties from the result. Let those callers that know they don't want such info throw it away - don't throw it away for them. The preservation of properties that are already there does not force anyone to use properties. Just like the possibility of using properties in a buffer.