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: Fri, 20 Jun 2008 21:59:35 -0700 Message-ID: <003401c8d35b$9a50cb50$0200a8c0@us.oracle.com> References: <001c01c8d325$4a595bc0$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 1214024407 19632 80.91.229.12 (21 Jun 2008 05:00:07 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 21 Jun 2008 05:00:07 +0000 (UTC) Cc: emacs-devel@gnu.org To: "'Stefan Monnier'" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Jun 21 07:00:51 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 1K9vDX-0000tQ-08 for ged-emacs-devel@m.gmane.org; Sat, 21 Jun 2008 07:00:51 +0200 Original-Received: from localhost ([127.0.0.1]:55210 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1K9vCi-0005YI-A2 for ged-emacs-devel@m.gmane.org; Sat, 21 Jun 2008 01:00:00 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1K9vCd-0005YD-FV for emacs-devel@gnu.org; Sat, 21 Jun 2008 00:59:55 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1K9vCc-0005Y1-M9 for emacs-devel@gnu.org; Sat, 21 Jun 2008 00:59:55 -0400 Original-Received: from [199.232.76.173] (port=46497 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1K9vCc-0005Xy-Ie for emacs-devel@gnu.org; Sat, 21 Jun 2008 00:59:54 -0400 Original-Received: from agminet01.oracle.com ([141.146.126.228]:38605) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1K9vCc-0002JA-3e for emacs-devel@gnu.org; Sat, 21 Jun 2008 00:59:54 -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 m5L4xoTf006343; Fri, 20 Jun 2008 23:59:51 -0500 Original-Received: from acsmt350.oracle.com (acsmt350.oracle.com [141.146.40.150]) by rgmgw1.us.oracle.com (Switch-3.2.4/Switch-3.2.4) with ESMTP id m5L3axZ1013369; Fri, 20 Jun 2008 22:59:50 -0600 Original-Received: from inet-141-146-46-1.oracle.com by acsmt351.oracle.com with ESMTP id 3697366031214024373; Fri, 20 Jun 2008 21:59:33 -0700 Original-Received: from dradamslap1 (/24.5.171.3) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 20 Jun 2008 21:59:33 -0700 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: Thread-Index: AcjTRER3Mlcm7gnxR+2FKgRYALLP9wAESmJg 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:99585 Archived-At: > > Back in 2007 (thread "display-completion-list should not strip text > > properties"), I argued that completion candidates should be able to > > have text properties and the result read should retain those > > properties. Richard OK'd that change. > > IIUC completion candidate's properties are preserved when displayed in > *Completions* now. So part of it is done. > > I think that to make read-file-name preserve properties, you'd need to > make substitute-in-file-name preserve properties. It's > doable, but it's > a non-trivial amount of work and it's not clear how useful that would > be, so ... patches welcome, especially together with some compelling > example showing why it's useful (rather than some vague principle). I already said I don't have any particular example in mind. The logic and reasons are essentially the same as for `completing-read', however - see the referenced 2007 thread. Actually, however, I just realized that the situation is different from what I thought. In the thread about `display-completion-list', the request I made, and the aim, was not just that `display-completion-list' be able to display candidates that have text properties, but also that `completing-read' return such a chosen candidate, with its properties. IOW, that `completing-read' would respect text properties in the user's input, not just in the completion candidates, returning the possibly propertized string that the user chooses. Apparently, that part was never implemented - `completing-read' still strips text properties. And, since `read-file-name' is now implemented using `completing-read', so does `read-file-name'. The good news is that if what was requested and OK'd last year gets implemented, then it will also hold for `read-file-name'. I can see that because I have a version of `completing-read' that preserves text properties, and when I call `read-file-name' in Emacs 23, it too preserves text properties. IOW, AFAICT, there is no need to modify `substitute-in-file-name' or `read-file-name'. It is only `completing-read' that needs to be fixed to allow this. The rest will follow. The reason I didn't see this at first is that Icicles uses a version of `completing-read' that DTRT: doesn't strip text properties. So `read-file-name' also doesn't strip them, which led to the problem with the GNUS code that blindly print the propertized string as a Lisp #("..."...) form. I thought the problem was `read-file-name', but it is the vanilla `completing-read' that is the only problem. I hope you will consider making the change to `completing-read', so it returns whatever string the user inputs, including its text properties, if any.