bug#27193: 25.2; tmm should use completing-read-default

[Drew Adams]

> > The case that needs to be made for your proposal is really (IMO) that
> > there are /NO/ values of `completing-read-function', apart from
> > `completing-read-default', which would be compatible with the tmm code.
> 
> That would be too strong.

No.  That's exactly what you're forcing, if you force
`completing-read-default' as the ONLY possible value.

Precisely that: you allow no other values.  The claim
behind that must be that ALL other values would be
problematic and so must be disallowed.

> > I don't think you can make that case. I sense you
> > are extrapolating from your own particular use of
> > `completing-read-function' (and similar uses).
> 
> This is ridiculous. If there are functions that adhere to the contract
> of completing-read-function, and tmm can't work with them, tmm should
> use completing-read-default, and that's that.

"Adhere to the contract of `completing-read-function'"?
Are you kidding?  What contract is that?

 (defvar completing-read-function 'completing-read-default
   "The function called by `completing-read' to do its work.
 It should accept the same arguments as `completing-read'.")

Just accept the arguments - that's the only contract.
"Do the work" of `completing-read' is completely vague.

That means that anytime you can come up with a function that
accepts those args and causes trouble, `completing-read-default'
should be imposed as the only possible value.

THAT is ridiculous.

> I'll install the submitted patch in a few days if someone 
> doesn't beat me to it.

Of course you will.

> > The result is not even recognizable as completing-read.
> >
> > I don't think so. Certainly no more unrecognizable than Ido...
> 
> You are mixing up concepts right and left. E.g. APIs with their callers.

Nonsense.  Ido's completion behavior is as far from that of
vanilla `completing-read' as is Tmm's completion behavior
("the result").