RE: Questions about the `completing-read-function' interface

[Drew Adams]

> I'd like to know, if a function calls `completing-read', should the
> members of DEF be inside COLLECTION? I haven't found info on this in the
> doc, and `completing-read-default' doesn't seem to handle DEF not being
> in COLLECTION.

Completion can be lax: user input need not match any of the completion
candidates (null REQUIRE-MATCH argument).  Whether DEF is one of the
candidates is generally irrelevant in this case.

And COLLECTION can be a function, returning any string it wants.
It can even return a value that cannot be known at coding time.
What applies to user input pretty much applies to what DEF can be.

So in the general case no, DEF need not be one of the candidates
(or a subset of them, if it is a list).

The calling function (context) knows whether DEF should be one of
the candidates.  And only the calling function.

> But, for instance, `magit-completing-read' (and some other functions) do
> make that assumption.

Then they need to prepare for that assumption.  They have a particular
requirement for the relation between COLLECTION and DEF, and they need
to manage that use case.

> And `helm-mode' has code to deal with that.  I'm thinking of adding a
> similar work-around to `ivy-mode' as well, but maybe it would be better
> if it was somehow mandated that DEF should be in COLLECTION.  Because,
> theoretically, DEF can be a list, and it would be inefficient for the
> completion engine to go through the whole collection just to make sure
> that DEF isn't there, and then add it there.

Please don't.  Any given *caller* of `completing-read' that needs to
rely on DEF being a member (or a subset) of COLLECTION can just DTRT.

> As second question is about this interface:
>     (setq completing-read-function 'foo)
> 
> We've accumulated a bunch of packages that call this: icomplete-mode,
> helm-mode, icy-mode, ivy-mode.

(Not `icy-mode', FWIW.  But it does use `read-file-name-function'.)

> If these functions are called in succession, each of them will think
> that they are on, however, the resource (`completing-read-function')
> will belong only to the last one.
> Maybe we could have this type of interface:
>     (set-completing-read-function 'foo callback)
> 
> So that each time `set-completing-read-function' is called, the current
> minor mode is properly shut down in the callback.  We could keep the
> current interface for single-use completion through a let binding. But
> all the minor modes mentioned would use `set-completing-read-function'.

Again, please do not try to hard-wire any such behavior.  Leave it
up to the various libraries or other callers of `completing-read' to
handle any such possible interactions, if they see the need.

What I hear so far sounds like solutions in search of problems.
Or perhaps a case of the X-Y problem.  Instead of talking solutions,
perhaps you can present the real problem you are looking at - what
is it that you are trying to do?