bug#27158: 25.2; Eliminating old usage of completing-read from built-in files

[Dmitry Gutov]

On 5/31/17 5:51 PM, Drew Adams wrote:

> What's not necessary?  The argument is either optional or mandatory.
> If optional, what default behavior do you want?

The one I mentioned in the next paragraph in my previous email.

> Or are you saying that the default arg should just be removed
> from `completing-read', because "it's not necessary"?  Not
> necessary for whom?  Why isn't it ever a useful thing to have?

No, I mean that having the default argument when it's not specified, is 
not necessary. There is no need for "default default".

> Just because some callers might not need it does not mean that
> it is not useful for other callers.

They can use the DEFAULT argument.

> > Prohibit them from finishing completion, except through entering
> > a valid value, or pressing C-g.
>
> (while <no valid value> <get input with completion>)
>
> Is that hard?

It makes completing-read-function calling convention more complex for no 
real gain. The simpler the API is, the easier it is to provide 
alternative implementations for.

And also, we will have new callers who are not aware of this quirk. 
Those packages might fail to account for the possibility that 
completing-read can return "". After all, they passed t as the 
REQUIRE-MATCH argument.

> What happens when you set `completing-read-function' to your
> `my-completing-read'?

Some callers rely on it returning an empty string when the user presses 
RET. In those cases, if my-completing-read does not provide this ability 
(literally, does not return "" when the user presses RET right away), 
the user experience can suffer.

And some UIs make it non-trivial for the completing-read-function to 
behave like above. E.g. add "" to the completions list but only when the 
user does not type anything.