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

From: Drew Adams <[email-masked]>
Date: Thu, 30 Jan 2025 17:32:24 +0000

> >> Minibuffer-related
> >> variables are often let-bound around a completion call, which is not
> >> correct in a strict sense, since the variable should only hold inside
> >> the minibuffer and not for nested completion sessions.
> >
> > So it's _not_ really a redundancy.
> >
> > If what you _want_ for a given completion call
> > is to affect everything that transpires during
> > that call, i.e., including "nested completions"
> > (recursive edits), then binding a dynamic var
> > around the call gets you what you want, simply.
> 
> This is almost never correct nor desired, as you acknowledge yourself
> below.

You're exaggerating.  "Usually" and "often" are
not the same as "almost always".

> This means that even if the variable is not an exact redundancy,
> in the cases where behavior differs, usage of the variable leads to bugs
> or incorrect behavior.

No, it doesn't, if the behavior it effects is
_intentional_.  It's fair to say that its usage
_can_ lead to bugs or incorrect behavior.  But
that's true of most Lisp constructs.

> It is an argument in favor of deprecating the
> variable, if the variable can easily be used incorrectly.

Emacs provides 8 zillion ways to shoot yourself
in the foot.  Powerful language constructs can
be problematic if "used incorrectly".  Nothing
new here.

> >> The completion metadata including the category
> >> does not have this problem.
> >
> > Or this advantage/possibility.
> >
> > (I do agree that this deep dynamic-var behavior
> > is usually not needed or desirable during
> > completion.)
> 
> Indeed.
> 
> >> The deprecation of `minibuffer-completing-file-name' is just
> >> one step in the transition to the category mechanism. As I have
> >> mentioned the variable `minibuffer-completing-symbol' had been
> >> deprecated and has even been removed already.
> >
> > Meme combat, oui. ;-) Shouldn't have been removed.
> > (Also not redundant, for the same reason.)
>
> Again, we disagree about this - I think the deprecation and removal was
> the right thing. There does not seem to be a new argument here and it is
> up to the Emacs maintainers to decide about this matter anyway.

It's quite logical, and it can be useful, to want
all code executing during a file name (or buffer
name or whatever) read with completion to be _able
to know_ that such a completion (e.g. file-name)
is in progress (ongoing).  That's what such vars
do: they let code that executes during a given
kind of completion (e.g. file-name) _be aware_ of
that fact.

That can include code that uses the minibuffer
(with or without completion) for other purposes.

Such "meanwhile" code is just a part of what's
involved in that overall file-name (e.g.) read,
_whether or not it's aware_ of that.  And with
such a variable binding it _can be_ aware of it,
which means - a bonus - that its own behavior
can take that fact into account (maybe changing
prompt wording or whatever).

After all, that (e.g. file-name reading) is the
_overall_ operation in such a context.  (And like
a transaction, it can be "rolled back" (C-g, C-],
C-M-c) or ended normally ("committed").

[Of course it need not be absolutely _the_ overall,
i.e., outermost, operation.  A file-name reading
could itself be a "meanwhile" operation occurring
during an outer operation.  The usual Lisp nesting
and `let' nesting apply.]

This is a _positive advantage_ of let-binding a
variable such as `minibuffer-completing-file-name'.
This should be obvious to all, but apparently it
isn't.

What's more, nothing prevents such a "meanwhile"
inner completion from adding different categories
from `file'.

What should be done is enable category handling
to better cooperate with `minibuffer-completing-*'
vars, e.g., allow categories to override var
behavior, and even vice versa.  TO-DO.

As usual with Lisp and Emacs, one size does not
fit all.  Not without kneecapping greater
possibilities.