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

[Gregory Heytings]

> > > If the M-: is not in a recursive minibuffer, everything is OK since 
> > > icomplete-simple-completing-p returns nil.
> >
> > Indeed; patch attached.  Ideally this should be done inside 
> > icomplete-minibuffer-setup, but if we did this (by checking 
> > minibuffer-completing-symbol), it would prevent icomplete-mode from 
> > being active in the opposite situation: M-: followed by C-x C-f.
> >
> > @@ -1754,7 +1754,9 @@ read--expression
> >            (set-syntax-table emacs-lisp-mode-syntax-table)
> >            (add-hook 'completion-at-point-functions
> >                      #'elisp-completion-at-point nil t)
> > -          (run-hooks 'eval-expression-minibuffer-setup-hook))
> > +          (run-hooks 'eval-expression-minibuffer-setup-hook)
> > +          ;; if we enter a recursive minibuffer, disable icomplete (bug#45474)
> > +          (setq-local icomplete-mode nil))
>
> Is this really specific only to read--expression? I can reproduce the 
> same issue with any command that doesn't use completion, e.g. C-x C-f 
> C-x f.

Indeed, but the bug report was only about read-expression.  It's far more 
annoying to see completion candidates when you want to type a complete 
expression than when you just have to enter a short argument.

Anyway, given that you asked for it, here's a more general solution.  I 
did not check all places where read-from-minibuffer is used, but adapting 
them is straightforward.

Make-it-possible-to-disable-icomplete-mode-in-recurs.patch
Description: Text Data