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

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

>>> Indeed, but... it doesn't help/incite them to move forward in the "right"
>>> direction, to finally have what has been on wishlist for quite a long
>>> time: to have buffer-local minibuffer-completion-* elements...
>> It helps by showing how to do it.  I haven't seen any proposal here which
>> helps further than that (except maybe for some proposals which might break
>> such code, thus inciting them to use a better approach ;-).
> I believe that creating an optional behavior that is easy to use, and
> stating that that behavior will become mandatory in the next major Emacs
> release, is a stronger incentive.

We could add some "break old code" option, indeed.
I think we can do that with pretty much all the proposed patches.
We could also add a "warn when detecting old code" option; again
I suspect that this can be done with most of the proposed patches so far.
So, it's rather orthogonal to the choice of which approach is preferable.

>>> But when the let-bindings are in a macro the caller doesn't have to care
>>> with them, and they are indeed happening as close as possible to
>>> internal-read-from-minibuffer.
>> AFAICT you're talking about the let-bindings of `minibuffer-local-*`
>> whereas the problematic let-bindings are those of
>> `minibuffer-completion-*` and those are outside of `read-from-minibuffer`.
> 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.

> My aim here was to (help to) fix the nine years old "FIXME:
> `minibuffer-completion-table' should be buffer-local instead."  What would
> you do to fix it, in an ideal world in which backward compatibility is not
> an issue?

The patch I sent does just that.


        Stefan