bug#45474: Icomplete exhibiting in recursive minibuffer when it shouldn’t

[Juri Linkov]

>>> If not, it means that your patch will fix the problem for
>>> completing-read-default, but not for other completion backends, who will
>>> have to resort on a similar trick to get the same effect.
>>
>> I think they'd need to make similar changes to fix the problem under
>> discussion in this longish thread, but they can keep using their old way
>> of working and the consequence will just be that they will keep suffering
>> from the old problem.
>
> With my patch all they have to do is to add (minibuffer-local-completion t)
> before calling read-from-minibuffer.

Since other completion backends need to add (minibuffer-local-completion t)
anyway, the safest and most backward-compatible solution is to set
this new variable buffer-local in completing-read-default with

          (minibuffer-with-setup-hook
              (lambda ()
                (setq-local minibuffer-local-completion t))
            (read-from-minibuffer prompt initial-input keymap
                                  nil hist def inherit-input-method))))

Then modes like icomplete interested in knowing whether the minibuffer
was created for completions, can check for the buffer-local value
of minibuffer-local-completion.