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

[Drew Adams]

> completing-read-default still supports a behavior that is, as
> far as I know, a legacy feature that is kept only for backward 
> compatibility with code that was written before the default
> argument was added:

The default arg has been available since the beginning, AFAIK.
The behavior you describe is no more legacy than is providing a
default-value arg.  Nothing to do with backward compatibility,
I think.

> if the input is empty and the user presses RET, it will return
> the empty string, even if require-match is non-nil and the empty
> string is not in the collection.

And it returns the default, even if REQUIRE-MATCH is non-nil
and the default is not in the collection.  Do you dislike
that behavior too?

"" is just the default default, if you like (or not).

Would you make a default arg be mandatory instead of optional?
Is that it?  If not, what default default would you propose?
What should be returned if no explicit default is provided and
the user hits RET with no input?

"" seems like a great choice for the default default, to me.
It's pretty much guaranteed never to coincide with any usable
completion candidate (which is not the case for a non-empty
default value).  For one thing, that lets you easily check
whether the user chose one of the candidates, even in the
case where the collection is complex (e.g. a function).

> This quirk

Why is it a quirk?

IN any case, nothing stops someone from defining their own
`my-completing-read', which does not have this feature, er,
quirk.  I don't see the problem.

> is a thorn in the side of packages that provide alternative
> completing-read functions such as ido-ubiquitous an
> ivy-mode, which both want to have RET return either the
> default or the first choice on the list, not the empty string.

They can do exactly do that - just by providing that as the
default arg.  RET with no input returns the default already.
If you want to return the first candidate by default then
just pass that candidate as the default arg.  What am I
missing?

I also don't see the behavior as a thorn in the side of all
packages that provide alternative kinds of completion.  But
you don't really say what you mean by a thorn, here.

And I don't see it as a thorn in the side of other uses of
`completing-read'.  `completing-read' is a quite general
function.  Just because some particular user or package
might not use it in every way possible is not a reason why
its behavior should be limited to what some package uses.
Nothing prevents a package from always supplying a default
arg other than "".

The doc string says:

 If the input is null, ‘completing-read’ returns DEF, or the
 first element of the list of default values, or an empty
 string if DEF is nil, regardless of the value of REQUIRE-MATCH.

That's the design.  What part of it do you not like, and
why?  What's the thorn/quirk?

Sorry, but I don't see what problem you are trying to solve.
Is it the need to specify a default other than "" when you
don't want that default default?

> While this behavior can probably not be changed without
> breaking backward compatibility,

Yes.

> we can at least eliminate every use of the feature in the
> elisp files included with Emacs.

Why would we do that?

It's up to calling code to decide what behavior it wants
for RET with no input.  Yes, probably there are some cases
in existing code where a better default value might be
provided.  That's something to be looked at case by case.
So far, I don't see a general problem to be fixed.  Where's
the bug?