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

["Drew Adams" <drew.adams@oracle.com>]

> > http://lists.gnu.org/archive/html/emacs-devel/2007-01/msg00807.html
> 
> This lists uses of properties in completion candidates (typically when
> displayed in *Completions*).  As mentioned, this should already
> work now.  We're discussing a different issue, which is the text
> properties of the value returned by `completing-read'.
> 
> I'm not fundamentally opposed to this change, but I strongly suspect
> that any code that relies on those properties will be very 
> brittle since there is very little control over them.

No idea what that means. I've used this feature for years, and nothing has
broken.

But I don't really care. I don't want to get into a tug of war over this.

> So, if you can come up with
> actual scenarios where those properties could be 
> useful/important, maybe
> we can make sure not only that they're returned but that they are
> returned reliably.  If you can't come up with such a scenario, that
> casts doubts on the usefulness of the requested change.

I've no desire to belabor this. I'm not selling anything. If you don't want to
do it, please don't.

The general argument is that `completing-read' should be lossless; it should be
only about choosing, not losing info. Why? Why not? There is no reason that it
should lose info.

You agree that it should accept a set of rich structures, display them, and let
you choose from them. So far so good. Why should what you get back be only a
stripped down string instead of the whole structure you chose, including
properties that might not be visible? It's not only about rich display (color
etc.); it's also about choosing possibly complex objects. It's not only visible
properties that are useful.

Using properties lets an application pass along additional information about a
candidate choice, in addition to the string text - not just to *Completions* but
to the `completing-read' caller as the return value. The info can group/classify
candidates, order them, or do anything else you want.

I mentioned that I put that to advantage in Icicles in various contexts. I
associate different kinds of info with candidates, sometimes even candidates
whose appearance is the same: tag info, buffer locations, Info structure,
bookmark info, annotations, internal representations, and so on. 

Are there other ways to associate additional info with string candidates,
besides using text properties? Sure, and I use some of them too. But why not
provide this capability?

If the general rationale (don't lose info) doesn't convince you, and the
suggestions of uses don't inspire you, fuggedabowdit.