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

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

> So given your recommendation that alternative completion
> functions should "punt" cases they can't handle back to
> completing-read-default, along with the high likelihood
> that every alternate completion system is going to have
> something that it can't handle and needs to punt on, would
> you be interested in a patch that implements that punting
> mechanism within completing-read itself, so that
> ido-ubiqutous, ivy, helm, and others don't all have to
> invent their own punting code? I'm thinking along the lines
> of wrapping the call to completing-read-function with a
> condition-case that catches a "completing-read-fallback"
> signal, and calls completing-read-default instead. So any
> completion system that wants to punt just has to throw
> the appropriate signal.

First, I can tell that you have read and thought about
what I wrote.  Thanks for that.  I have not wasted my
time, in that case.

For the rest, as you can probably guess, I'm not in
really in favor of changing `completing-read'.

Tmm is something I don't really care about.
`completing-read' is something I do care about.
A priori, I would prefer that you do whatever it is
that you think you need to do to `tmm.el' than to
`completing-read' and related code.

That said, what you say does not sound objectionable.
It might be helpful.  But I represent just one opinion,
and I haven't really thought about this.

If you think such control is something that could be
generally helpful then I'd suggest that you bring it
up for discussion on emacs-devel@gnu.org.  That should
help.

In terms of implementation, maybe `catch' and `throw'
would be a better fit than `condition-case' with a
signal handler, but maybe not.  And you might have to
worry about where handling takes place, in case of
recursive completion - dunno.