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

[Stefan Monnier]

> What's wrong with my approach, which disables the completion backend on
> demand?

[ I'm not sure which is "your approach", sorry.  ]

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

Of course, this ties-in with the discussion about `minibuffer-mode`
where I mentioned that I think the minibuffers should use dedicated
major modes, and that which major mode to use should be indicated via an
argument passed to `read-from-minibuffer`.


        Stefan