Subject: RE: [External] : Re: bug#75910: 31; Deprecate minibuffer-completing-file-name

From: Drew Adams <[email-masked]>
Date: Thu, 30 Jan 2025 19:11:21 +0000

> >> Right now, the let-binding of minibuffer-completing-file-name around
> >> completing-read means that all inner completion sessions also complete
> >> file names. This is simply not correct.
> >
> > No, it doesn't - it shouldn't.  It means that
> > they're made aware of the fact that a file-name
> > completion is in progress.  They occur _during_
> > that file-name completion.  It's just a variable.
> > They don't need to, themselves, complete a file
> > name.
> 
> This interpretation is convoluted but correct. Congratulations.

You can drop the snark.

> Now we
> can talk about scenarios where we want this specific knowledge about
> outer completion sessions, which do not necessarily apply to the
> currently active completion session.

Knowledge of an outer completion being in progress
always applies to the currently active completion.
It need not care, but it's always applicable.  It
can care and take advantage of that knowledge if
it wants too.

It should be up to the coder and code to decide.

All Elisp needs to do is provide ways to enable
users to do what they want.

`let' bindings already DTRT wrt nested contexts.
AFAIK there's no problem with nested bindings of
`minibuffer-completing-*' vars.  They just
determine whether a given kind of completion is
said (declared) to be in progress.  But yes, an
inner binding of `minibuffer-completing-*'
shadows an outer one if it's the same variable.

How _categories_ handle such things (including
together with bindings of `minibuffer-completing*'
vars) is something else again - maybe there's some
work to be done there; dunno.  I only requested
the `category' feature; I didn't implement it.
Maybe it's still a work in progress:
(let ((category-feature-completing v1)...)