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

[Gregory Heytings]

> > What's wrong with my approach, which disables the completion backend on 
> > demand?
>
> [ I'm not sure which is "your approach", sorry.  ]

See the attached patch.  I's a draft, as I said 
read-from-minibuffer-simple could probably renamed to something more 
elegant, and (at least some of) the other calls to read-from-minibuffer 
could be replaced by the macro.

> > A variant of it would be to add an eight argument to 
> > read-from-minibuffer.  AFAICS it's only the caller that can know 
> > whether the completion backend should be used, IOW, the only thing that 
> > the completion backend can do is to obey the caller.
>
> We should think hard before adding yet another argument.

Yes ;-)  Which is why I did not do that.

> I agree that the current design is problematic.  Basically, I think that 
> `minibuffer-completion-table` should be set buffer-locally in the 
> minibuffer instead of being "set" by dynamic scoping.
>
> Fixing the problem "right" might call for a significant redesign of 
> `read-from-minibuffer`s API and `completing-read`s implementation.
>
> A quick&dirty workaround for now would be for `completing-read` to set 
> some var alongside `minibuffer-completion-table` which indicates *which* 
> minibuffer this is for (e.g. some minibuffer-depth information). This 
> way `read-from-minibuffer` could distinguish a 
> `minibuffer-completion-table` passed for the current invocation from one 
> passed for the outer invocation and could hence temporarily rebind 
> `minibuffer-completion-table` to nil.
>
> Another approach would be for `completing-read` not to let-bind those 
> vars but instead to use `minibuffer-setup-hook` to set the vars 
> buffer-locally.

These are yet other possible approaches indeed, but it seems to me at 
first sight that they are more complex than the solution I suggest.

Make-it-possible-to-disable-a-completion-backend-in-.patch
Description: Text Data