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

[Drew Adams <drew.adams@oracle.com>]

> > I don't know what more to say.  Not being able to
> > have `minibuffer-completion-table' dynamically
> > scoped and settable/redefinable as such a variable
> > would effectively destroy Icicles features that
> > rely on exactly that ability.
> 
> Let me rephrase my question:
> What makes you think that having them be set
> buffer-locally rather than via a global let-binding
> would prevent Icicles setting/redefining them?

Let-binding of global, dynamic variables (defvar)?
Or something else?

I don't know what making such vars buffer-local might
do to the (Icicles) behavior.  It's not even clear to
me what buffer-local means for the minibuffer these
days (what with experiments/proposals about changing
its mode etc.).

It's possible that the effect wouldn't be nefarious.
But it's also possible it would be.  During minibuffer
use, other buffers can be current at various points,
for example.  But I'm not sure there's a problem there.

My reason for posting was that you were, or I thought
you were, contrasting dynamic and lexical binding, of
`minibuffer-completion-table' (and maybe similar vars).

It's dynamic binding that my code depends on for such
vars.  Dunno how important (for my code) global vs
buffer-local is in this context.  That's something
different.

Am I mistaken that you seem to have switched from a
consideration of dynamic vs lexical to global dynamic
vs buffer-local dynamic?

I'm sorry; I haven't followed this discussion.  I
just wanted to give a heads-up that it would be
problematic for me if such vars were made lexical or,
say, were simply passed as args.  I bind and set them
as dynamically-scoped vars.

If necessary, I can dig out examples of what I do.
I hope it doesn't come to that, though.