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

[Oleh Krehel]

Stefan Monnier <address@hidden> writes:

>>> 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?
>
> If require is t I think it'd be OK for the completing-read function to
> ignore any DEF argument which is not in COLLECTION.
>
> For the same reason, M-p should arguably skip history members which
> aren't in COLLECTION (or which are rejected by PRED).
>
> But there are some issues: even if DEF (or history elements) would be
> rejected by require-match when you hit RET, it might still be a useful
> string to get via M-n (which the user then completes before hitting RET).
>
>> 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.
>
> But this extra complexity only "solves" the very narrow problem you're
> facing, while introducing non-trivial issues: what about minor modes
> that override completing-read-function but which only apply to some
> cases?  There can be several such minor modes active at the same time
> without conflict.
>
>> There's no way to end up in a worse state than is now.
>
> Well yes, there is: increase code complexity for little benefit is
> a worse state.

It's not that much more complex. Currently, we have this behavior for
major modes. When one is activated, Emacs deactivates the second one.

We could get the same feature for themes, or company-mode/auto-complete,
there are plenty of use cases.

>>> 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?
>
> M-x ivy-mode RET
> M-x helm-mode RET
> M-x ivy-mode RET
>
> You should now have helm-mode active and working properly, yet with your
> current code, helm-mode will be "enabled by inactive".  If you use
> add/remove-function this case will be handled correctly.

I meant to give an example of how `add-function' helps here.  Also, with
your sequence of commands, starting from nothing, we have ivy-mode set
to "t" and having the `completing-read-function' resource,
while `helm-mode' is also "t" and may think that it has the resource,
but it doesn't.

I've also seen this type of code: ido-vertical-mode stores the variable
`ido-decorations' of ido-mode and modifies it.  When you turn off
ido-vertical-mode, it restores `ido-decorations'.  But what if other
code has changed `ido-decorations' in the meantime, while
ido-vertical-mode is still on?  Any way you put it, the result is
incorrect. Unless there's a robust system behind it all that manages the
`ido-decorations' variable.

Oleh