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

[Gregory Heytings]

> > Aren't these problems orthogonal to the problem at hand?  It seems to 
> > me that this is not different from the traditional way of passing 
> > arguments to a function; of course something unexpected can happen when 
> > they are evaluated, before the function is entered, but that's 
> > something outside the responsibility of the function.
>
> No, the problem is not "can someone change `minibuffer-completion-table` 
> before we get to its intended consumer" but "will the let-binding of 
> `minibuffer-completion-table` also affect code which was not the 
> intended consumer". This problem does not exist with 
> traditional/explicit argument passing.

Again, it seems to me that this problem is not directly related to the 
problem at hand.  If the caller of read-from-minibuffer is not careful 
enough and binds minibuffer-completion-* too far from the call, in such a 
way that other code is unexpectedly affected (or could unexpectedly be 
affected) by this binding, it's the responsibility of that caller to fix 
that problem.

Anyway, I attach a last version of my patch, in which all the dancing 
happens at the C level.  It is probably also possible to finally get rid 
of the 15 lines with the minibuffer-completing-file-name = Qlambda hack in 
read_minibuf().

Make-it-possible-to-disable-a-completion-backend-in-.patch
Description: Text Data