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

[Gregory Heytings <gregory@heytings.org>]

>> 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.

>> 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.

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?