RE: should read-file-name not respect text properties in its input string?

[Drew Adams]

> > 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.