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

[Oleh Krehel]

Stefan Monnier <address@hidden> writes:

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

I agree for the case of

    (memq require-match '(nil confirm confirm-after-completion))

What about the other cases?

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

Oops, I forgot. It does some weird thing with the hook instead.

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

I think it could be handled better without any disadvantage:

1. all minor modes subscribe with `set-completing-read-function'
2. user calls M-x mode-1. mode-1 is active and subscribes.
3. user calls M-x mode-2. Emacs sends a message to mode-1 to shut
down. mode-2 is active and subscribes.
4. and so on.

There's no way to end up in a worse state than is now. And the modes
that don't subscribe simply don't get the benefit of knowing that they
don't own the resource any more. Just like it is now.

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

It's harmless in this case. It just causes an annoyance for the user to
do M-x ivy-mode twice before it's actually active.  There are other
contested resources besides `completing-read-function', like keymaps or
windows. For example, hydra messes with `input-method-function', a
resource that belongs to `key-chord-mode'.

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

I don't understand. Can you give an example?

Oleh