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.

I think the same thing should hold for `read-file-name', not just
`completing-read': If you provide input that has text properties, the file name
returned should retain those properties. IOW, stripping properties should not be
part of the job of reading file names.

That's the behavior I've had in Icicles. But I've discovered that some other
code (GNUS, it seems) naively chokes if `read-file-name' returns a string that
has text properties. So I've backed off in Icicles - I now strip properties in
my version of `read-file-name', to be compatible. Dommage.

I'd still like to pose the question here, however. Shouldn't `read-file-name'
just return the string that you choose, including any text properties it might
have? If we made that change, then some code (e.g. GNUS) that expects there are
no properties might need to be fixed to first remove all properties.

There might not be any obvious need for a file-name string that has properties,
but neither is there any a priori reason to strip properties that might be
included. An application might well want to take advantage of properties here in
some way.

The place where a user reported a problem with this was GNUS or mml (it seems)
simply printing (into an XML attribute value) the file name that was read,
without first stripping any properties. That is, it uses the wrong Lisp print
function, producing crap like this:

<#part type="text/plain"
       filename=#("~/test.txt" 0 10 (auto-composed t))
       disposition=attachment description=test>
<#/part>

I would think that a program that creates XML code would take the trouble of
verifying such data before sticking it in, but, ahem, this is the real world.
;-)

To me, it's the job of any caller that wants no properties to strip them out;
that shouldn't be the job of `read-file-name'. Anyone else feel that
`read-file-name' should remain general and agnostic wrt the presence of text
properties in the string it reads?