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

[Stefan Monnier]

OK, seeing how noone reported problems with my patch, I pushed it to
`master`.  In case someone later reports a problem, we may "revert" to
your approach if its slightly better compatibility proves useful.


        Stefan


Gregory Heytings [2021-04-24 08:44:38] wrote:

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