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

[Drew Adams]

> I think we should change the calling convention of
> completion-read-function (while keeping completing-read the
> same, it will call completing-read-function passing (or DEF "")
> as the default).

The value of that variable is supposed to accept the same
args as `completing-read'.  Understood is that `completing-read'
just passes its args along to the value of `completing-read-function'.

Anything else makes it impossible for `completing-read-function'
to be as general as it should be.  It should be able to do
exactly what `completing-read' does now, if it wants.

If your particular value of `completing-read-function' wants
to consider the DEF arg value to really be `(or DEF "")' then
it need only act that way, no?

  (setq def  (or def ""))

End of story, no?  Why do you need to change the interface
of `completing-read-function' itself?

And if that is insufficient for some reason, can't you use
`advice-add' to redefine `completing-read' (e.g. in some
scope or for some duration) to do exactly what you need?

I sense that you have a real problem, but I'm not sure what it is.

A guess is that you would like `completing-read', within the
scope of some mode (e.g. Ido Ubiquitous), behave as if the DEF
arg it receives (where abscence is equivalent to receiving nil)
were in fact `(or DEF "")'.

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?

Why should your particular need be spread to everyone and
every use of `completing-read'?  Why should `completing-read'
or `completing-read-function' be stunted in this way?