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

[Gregory Heytings <gregory@heytings.org>]

>
> I wonder do you really intend to replace all hundreds of 
> read-from-minibuffer calls with read-from-minibuffer-simple? For 
> example, I use 'query-replace' a lot in the completion minibuffer, but 
> it's not fixed.
>

I don't know.  Either we can fix them one by one as bug reports are filed, 
or we can fix them in one shot, possibly with a shorter name (say 
"input-from-minibuffer" or "get-from-minibuffer").  I don't see why it 
would be wrong to do that, or what it could break; the macro is as simple 
as possible.

>
> To be able to narrow the fix to icomplete.el only, it's possible to 
> check the value returned from (minibuffer-depth) before icomplete kicks 
> in, and disable icomplete completions when the value is greater than it 
> was when entered the first minibuffer initially, thus handling recursive 
> minibuffers that don't provide completions.
>

I'm not sure I understand what you mean by this, but AFAICS 
minibuffer-depth cannot be used to determine whether icomplete (or other 
completion backends) should be activated or not.

If you do M-: C-x C-f, you want completions at minibuffer-depth = 1 and 
not at minibuffer-depth = 0; if you do C-x C-f M-:, you want completions 
at minibuffer-depth 0 and not at minibuffer-depth 1; if you do C-x C-f C-x 
8 RET you want completions at minibuffer-depth 0 and at minibuffer-depth 
1; if you do M-: C-x f you do not want completions at minibuffer-depth 0 
nor at minibuffer-depth 1.

>
> Or maybe simply disable previous icomplete when recursive minibuffer 
> doesn't use completions.
>

And how would you detect whether a recursive minibuffer expects 
completions or not?