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

[Drew Adams]

> > You agree that it should accept a set of rich structures, display
> > them, and let you choose from them.
> 
> Uh, _I_ don't agree.

"You" meant Stefan, to whom I replied. Richard OK'd that feature, and it's part
of Emacs. Take up your disagreement with Emacs.

> At best, this may be argued for completing-read
> with neither nil or confirm-only as REQUIRE-MATCH.  Other than that,
> user input can be passed into it that need not match anything in the
> completion list.

Read all of what I wrote. With lax completion your input need not match a
candidate, of course.

> Then it does not make sense that sometimes 
> information will be picked from the completions, sometimes not.

If an application depends on picking up additional information from a candidate,
other than just the stripped string, then it will use strict completion. (It
could conceivably somehow expect the user to input the appropriate propertized
text, but that would be unlikely.) 

If an app uses lax completion and user input doesn't match any candidate, then
the app had better not depend on any information that is not in the input.

> So what if there text properties in it, and the user input contains
> different text properties?  Is that supposed to be a 
> non-match?  

Matching is unchanged. Emacs uses ordinary string matching for completion: any
text properties present are ignored for matching. 

There is nothing new in this. `all-completions' and so on have worked with
propertized strings for a long time. And `display-completion-list' has enabled
matching against propertized candidates for a year.

What would be new would be to return the matched candidate, properties and all.

> Are the user input text properties to be thrown away?  Why would you want to
> throw the user input information rather than the completion 
> information away?

See previous. Emacs completion matching always ignores properties, regardless of
which string they belong to (candidate or input).

Nothing that is kept today would be thrown away. This is not about throwing away
information; it's about not throwing away information.

> > 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.
> 
> So why would you throw the properties in the user entry away when they
> did not come about by completion, but the user input matches a
> completion candidate?

Never said that.

> > 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.
> 
> Why would it do that if the information was not entered by completion,
> but merely matches a completion candidate by chance?

See above. If an app depends on additional info that is provided in completion
candidates, then it will use strict completion.
 
> > 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?
> 
> Because no consistent behavior has been proposed so far?

Forget it, David.

> > If the general rationale (don't lose info) doesn't convince you, and
> > the suggestions of uses don't inspire you, fuggedabowdit.
> 
> So why lose the info from the keyboard entry and replace it with the
> info of a completion candidate in case there is one?

If your input matches only one candidate, then that candidate is placed in the
minibuffer, and it is what is returned. That is nothing new. The difference is
that if the candidate has properties they are not lost.

If your input matches no candidate and completion is lax, then whatever is in
the minibuffer when you hit RET is returned - however it got in the minibuffer
(yanking, typing, completing plus editing,...). If your input for some reason
has text properties, they are included in the returned string.

Today, in neither case does the returned string have text properties.

> If the completion candidates are not even consulted (like when
> REQUIRE-MATCH is nil and TAB never is hit), why would I paste over the
> user's text properties?

You wouldn't. I never said that would happen.

Anyway, no sense arguing. Don't add this to Emacs.