GNU bug report logs - #75910
31; Deprecate minibuffer-completing-file-name

Previous Next

Full log

Message #80 received at 75910 <at> debbugs.gnu.org (full text, mbox):

From: Drew Adams <drew.adams <at> oracle.com>
To: Daniel Mendler <mail <at> daniel-mendler.de>
Cc: "75910 <at> debbugs.gnu.org" <75910 <at> debbugs.gnu.org>,
 Michael Albinus <michael.albinus <at> gmx.de>,
 Stefan Monnier <monnier <at> iro.umontreal.ca>
Subject: RE: [External] : Re: bug#75910: 31; Deprecate
 minibuffer-completing-file-name
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.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.