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

[David Kastrup <dak@gnu.org>]

"Drew Adams" <drew.adams@oracle.com> writes:

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

Uh, _I_ don't agree.  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.  Then it does not make sense that sometimes information
will be picked from the completions, sometimes not.

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

> 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?

> 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?

> 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?

> 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 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?

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum