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

[Stefan Monnier <monnier@iro.umontreal.ca>]

> It seems to me that my proposal is better, and here's why.  The right thing
> to do in this case is not to install a local fix in completing-read-default,
> because completing-read-default is not where the root cause of the current
> problem lies.

Hmm... that's odd: the problem has to do with values of
`minibuffer-completion-*` appearing where they shouldn't, and those
values are set by `completing-read-default`, so I think it's clearly
the culprit.

AFAIK The patch I'm proposing is (in the long term) doing The Right
Thing (tho not quite in The Right Way since it still uses
`minibuffer-with-setup-hook`, but that's an internal detail that can be
fixed in the future by changing `read-from-minibuffer` to offer some
other way to run code in the new minibuffer).

> The right thing to do is to change the semantics of
> read-from-minibuffer (while preserving backward compatibility for
> a limited amount of time), in such a way it receives some of its
> arguments through its environment.

The core problem is the fact that dynamic scoping leaks: the parameters
passed to `read-from-minibuffer` via dynamic scoping and up being passed
to all other uses of `read-from-minibuffer` which happen to take place
within the same dynamic extent.

I can't see how "The right thing to do" can be compatible with "receives
some of its arguments through its environment".
[ Note that I'm not saying that doing it is necessarily wrong for a
  short term fix, tho.  ]


        Stefan