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

[Stefan Monnier <monnier@iro.umontreal.ca>]

>> > 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.
>> 
>> Could you sumarize it or give an URL for it?

> Irrelevant, as I said, because `read-file-name' will automatically
> work if the job is finished for `completing-read'.

I did read what you wrote, so I meant a summary about completing-readm
not about read-file-name.

>> If from the minibuffer text (the only reliable choice), what kind of
>> properties would these be, who would put them there?

> If the input text comes from choosing a candidate (e.g. mouse-2, TAB
> completion), then whatever properties the candidate has. If the input
> comes from the user yanking propertized text, then whatever properties
> that yanked text has. Even if the user uses facemenu in the minibuffer
> to change the face of text s?he inputs, and then types text with that
> face, then whatever properties that text has.

> However the input text happens to become propertized, it should retain
> its properties when it is returned from `completing-read' (and so from
> `read-file-name' also).

So, again, what kind of properties would these be?


        Stefan