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

[Gregory Heytings <gregory@heytings.org>]

>
> I think we should:
>
> - Do something along the lines of the whitelist approach, as the "long 
> term" solution.
>
> - Add to it some "short term" heuristic (e.g. using something like the 
> "equal keymap" or the minibuffer depth) that keeps it working for 
> ivy-read and friends, maybe emitting a warning along the way (and with a 
> clean way to silence this warning when it's a false positive) so we can 
> remove the heuristic in Emacs-30.
>
> WDYT?
>

I've been thinking about this, and now have another potential solution in 
mind, which I'm not sure it is feasible.  The assumption of this idea is 
that the present problem is an instance of a more general problem, i.e. 
that similar problems will arise for other functions in the future.  The 
general idea is to make the following possible, when a function foo needs 
to be changed to depend on some variable bar or to accept an additional 
argument baz:

Emacs N:

- rename the function foo to internal-foo

- add a macro foo which (a) either calls internal-foo after setting bar or 
baz to a default value that make internal-foo behave as foo in Emacs N - 
1, or (b) calls internal-foo directly (i.e. assuming that bar or baz have 
been set appropriately)

The macro would (and here I'm not sure it is feasible) expand to (a) for 
external packages that have not yet been upgraded, and to (b) for those 
who have been upgraded and for Emacs core.  The question is: is it 
possible to have a predicate function to distinguish those two cases?

Emacs N + 1:

- remove the macro foo

- rename the function internal-foo back to foo

To illustrate the above with the present problem, read-from-minibuffer 
would depend on the value of completing-read-from-minibuffer, which would 
default to nil for Emacs core (and packages that have been upgraded) and 
would be let-bound to t in completing-read-default, and would default to t 
for external packages (that have not yet been upgraded).

>> Yes, I understood this, but the effect of let-binding the var and make 
>> it buffer-local after the minibuffer has been created but before the 
>> minibuffer-setup-hook is executed is the same.  Or am I missing 
>> something?
>
> [ Note: I consider this part of the discussion as not directly relevant 
> to bug#45474.  ]
>

Indeed ;-)  I guess the above idea is also a bit far from bug#45474...

>
> Oh, so `read-from-minibuffer` receives it as an "implicit argument" vet 
> dynamically scoped let-binding and then sets it buffer locally?
>

Exactly.  It receives an argument through its environment instead of an 
explicit one.