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

[Drew Adams]

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

> The main problem I have to understand how this could be used 
> is that if the user types the text, it won't get the properties
> from the completion candidates since the completion was never
> involved.

There are different ways to choose a candidate, and different ways to provide
input to `completing-read'. You can choose with the mouse. You can yank
propertized text in the minibuffer. And TAB completion too can put the
propertized candidate in the minibuffer.

> So do you want the properties from the completion candidates 
> or from the minibuffer text?

Whatever is in the minibuffer when the user ends completion (RET). If the user
chooses one of the candidates (however it is chosen), then it should be used,
together with its properties. If the user instead enters something else
(non-candidate with lax completion), whatever s?he enters should be used,
together with its properties.

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