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

[Stefan Monnier]

> 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.

So far we haven't tried to enforce this and if require-match is not set,
then I don't think we should require it.

> 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.

Actually, icomplete-mode does not touch completing-read-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.

Indeed.

> 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.

I don't think it's worth the trouble.  `completing-read-function' should
reflect the user's explicit choice, and if the user enables
several of those modes at the same time, she gets what she deserves.

IOW I think it's OK if ivy-mode thinks it's enabled and yet it is not
active because some other mode has overridden completing-read-function.

I agree that there are potential for actual problems if the
completing-read-function is not properly reverted when the modes are
disabled.  For that reason I recommend you use `add-function' and
`remove-function' rather than `setq'.


        Stefan