all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
* should read-file-name not respect text properties in its input string?
@ 2008-06-20 22:30 Drew Adams
  2008-06-21  2:06 ` Stefan Monnier
  0 siblings, 1 reply; 12+ messages in thread
From: Drew Adams @ 2008-06-20 22:30 UTC (permalink / raw)
  To: emacs-devel

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? 






^ permalink raw reply	[flat|nested] 12+ messages in thread

end of thread, other threads:[~2008-06-22  8:30 UTC | newest]

Thread overview: 12+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2008-06-20 22:30 should read-file-name not respect text properties in its input string? Drew Adams
2008-06-21  2:06 ` Stefan Monnier
2008-06-21  4:59   ` Drew Adams
2008-06-21 18:13     ` Stefan Monnier
2008-06-21 19:46       ` Drew Adams
2008-06-21 20:34         ` should read-file-name not respect text properties in its inputstring? Drew Adams
2008-06-21 20:44         ` should read-file-name not respect text properties in its input string? Stefan Monnier
2008-06-21 23:02           ` Drew Adams
2008-06-22  1:41             ` Stefan Monnier
2008-06-22  3:09               ` Drew Adams
2008-06-22  7:17                 ` David Kastrup
2008-06-22  8:30                   ` Drew Adams

Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.