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

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

> >> (defun completing-read (prompt collection &optional predicate
> >>                                  require-match initial-input hist def
> >>                                  inherit-input-method)
> >>     (funcall completing-read-function
> >>              prompt collection predicate require-match
> >>              initial-input hist (or def "") inherit-input-method))
> >> should suffice.
> >
> > It doesn't suffice.
> 
> Citation needed.

No "citation" needed.

`completing-read-function' needs to have the same signature
as `completing-read'.

I am the one who requested `completing-read-function' and
pushed to have it added to Emacs.  Its purpose is to easily
let you change the _complete_ behavior of `completing-read',
just by binding a variable.

That requires passing it exactly the same arguments, to do
as it pleases with them.  If, as in your case, it wants to
act as if DEF were in fact `(or DEF "")', it can do that.

If you want to simulate an explicit DEF when none is present,
that's easy enough to do in the function that is your value
of `completing-read-function'.  You don't need to force that
on all uses of `completing-read-function'.

Changing the signature of `completing-read-function' in the
way you suggest makes all uses of `completing-read-function'
follow the path you've outlined for `ido-ubiquitous-mode'.
That's a particular kind of completion.  No thanks.

And no need.  You don't need that, to make your mode do
what you want.  If you disagree, please show da codez: a
simple example that doesn't work and for which you see no
possible solution.

> >> My context is "the whole of Emacs". That's what Ido Ubiquitous
> >> is supposed to be affecting and improving.
> >
> > Really?  Even when `ido-ubiquitous-mode' is off?
> 
> Obviously not. Also not when it's not installed, in case you
> were wondering.

In that case, it's obvious that you can do whatever you need
inside the mode.  Do your (setq def (or def "")) there, for
use only by your mode.  You haven't shown why you think you
cannot do that.

> > Again: What prevents you from making `completing-read' behave
> > that way (or any other way) within your context?  Why is it
> > insufficient for you to do that in your value of
> > `completing-read-function' or by advising `completing-read'
> > for the duration?
> >
> > No answer.
> 
> You fail at reading.

Nonsense.  Why can't you use `completing-read-function' to
do what you want in your mode?

> > I change the behavior of `completing-read' considerably
> > more than what you've described, but I do it only inside
> > `icicle-mode'.  When the mode is off, the vanilla behavior
> > returns to `completing-read'.  Not a big deal.  Normal.
> 
> And yet, you haven't contributed anything helpful to this
> discussion so far.

Ooooh.

Please say why you cannot do what you need for just your mode.

`completing-read' is not intended to have only the behavior
you want.  But it is designed to _let you get_ the behavior
you want, as well as other behaviors.

There is a reason for the DEF argument, a reason for it to
be optional, and a reason for its default value to be "".
All of which I've gone over.

This thread was started by a misconception of what DEF is
for, thinking that it is useless.  It may be useless - or
even an obstacle to be worked around - for your use case,
but it is not useless for Emacs.

DEF was even expanded several releases ago, to allow a
value that is a list of default values.  Those too likely
don't fit your narrow use case.  Default values are
intentionally not completion candidates.  And yes, in
general they are useful, even if not for your use case
of `completing-read'.

If your use case calls for no default values, or in effect
wants to treat them as completion candidates, it's easy
enough for you to do that.  That is not the general,
default, intentional treatment of DEF by `completing-read'.