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

[Gregory Heytings]

> Oh, I see it's a more fundamental problem:

Yes ;-)

> 1. completing-read-default let-binds minibuffer-completion-table to a 
> collection before calling read-from-minibuffer;
>
> 2. any nested call to read-from-minibuffer reuses the same value of 
> minibuffer-completion-table, even if it doesn't use completion;

Not necessarily, if another completion table has been set during the new 
minibuffer invocation.  That's what happens with C-x C-f followed by C-x 8 
RET.

> 3. icomplete checks for minibuffer-completion-table to decide whether to 
> activate icomplete completions in the minibuffer.
>
> This is how non-completion minibuffers get non-nil 
> minibuffer-completion-table.
>
> 'read-string' solves this problem by let-binding 
> minibuffer-completion-table to nil before calling read-from-minibuffer. 
> 'read-number' could do the same. But what about all other calls of 
> 'read-from-minibuffer'?  They all can't be replaced with a new function 
> that will let-bind minibuffer-completion-table to nil.

You forgot one element of the problem: completing-read also uses 
read-from-minibuffer.  So you cannot simply use read-from-minibuffer => no 
completions, completing-read => completions.

> I have no idea how to fix this.  Maybe Stefan could help (Cc:ed).

What's wrong with my approach, which disables the completion backend on 
demand?  A variant of it would be to add an eight argument to 
read-from-minibuffer.  AFAICS it's only the caller that can know whether 
the completion backend should be used, IOW, the only thing that the 
completion backend can do is to obey the caller.