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

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

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

So are you arguing that DEFAULT should be a mandatory argument?
I addressed that in my first message.

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

So you do think that it is hard?  Hard to believe.

And how so, no real gain?  If there is no real gain for
you then don't do it.  You said you wanted to keep
prompting and getting input as long as the user tried
to exit with no input.  Now you are saying that doing
that would e no real gain.  (?)

> The simpler the API is, the easier it is to provide
> alternative implementations for.

By that logic we should get rid of most of the optional
args to `completing-read'.  Or maybe we should get rid
of `completing-read' and let people do it all using
`read-from-minibuffer'?

But go ahead.  Make DEFAULT mandatory if you like.
See how that change goes down.

But if an explicit DEFAULT arg is the solution then your
completion system need only set arg DEFAULT to "" when
it is nil, no?  Or set it to the first completion candidate
when it is nil or "".  Or ... <whatever floats your boat>.

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

Imagine that.  And they would rely on the same thing if they
passed "" as an explicit DEFAULT arg.

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

Indeed.  So don't do that.  Respect what the caller expects.

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

If you cannot test for "" return value then checking for
no input becomes even harder.

Sure, explicit "" DEFAULT provides the same possibility
for checking for input.

What does your `completing-read-function' want to do in
that case?

Sorry, but it's not clear to me what the problem is.
Anything I think I see you saying about the problem does
not seem to be solved by making DEFAULT mandatory.
What am I missing?  How about a concrete example?