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

Previous Next

To reply to this bug, email your comments to 75910 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

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

From: Daniel Mendler <mail <at> daniel-mendler.de>
To: bug-gnu-emacs <at> gnu.org
Subject: 31; Deprecate minibuffer-completing-file-name
Date: Tue, 28 Jan 2025 15:28:28 +0100

I propose to deprecate `minibuffer-completing-file-name', since the
completion category as part of the completion metadata acts as
generalization for this variable. Similarly `minibuffer-completing-symbols'
has been deprecated and removed a while ago.

Instead of checking `minibuffer-completing-file-name' one can use
(minibuffer-category-p 'file) given the following predicate function:

(defun minibuffer-category-p (cat)
  (eq (completion-metadata-get
       (completion-metadata
        (buffer-substring-no-properties
         (minibuffer-prompt-end) (point))
        minibuffer-completion-table
        minibuffer-completion-predicate)
       'category)
      cat))

Message #8 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>, "75910 <at> debbugs.gnu.org"
 <75910 <at> debbugs.gnu.org>
Cc: Stefan Monnier <monnier <at> iro.umontreal.ca>
Subject: RE: [External] : bug#75910: 31; Deprecate
 minibuffer-completing-file-name
Date: Tue, 28 Jan 2025 17:11:04 +0000

> I propose to deprecate `minibuffer-completing-file-name', since the
> completion category as part of the completion metadata acts as
> generalization for this variable. Similarly `minibuffer-completing-
> symbols' has been deprecated and removed a while ago.
> 
> Instead of checking `minibuffer-completing-file-name' one can use
> (minibuffer-category-p 'file) given the following predicate function:
> 
> (defun minibuffer-category-p (cat)
>   (eq (completion-metadata-get
>        (completion-metadata
>         (buffer-substring-no-properties
>          (minibuffer-prompt-end) (point))
>         minibuffer-completion-table
>         minibuffer-completion-predicate)
>        'category)
>       cat))

FWIW, I'm opposed to this.  You can as well
replace all of that with the longstanding
variable.

That you don't use something isn't evidence
that it isn't used.

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

From: Daniel Mendler <mail <at> daniel-mendler.de>
To: Drew Adams <drew.adams <at> oracle.com>
Cc: "75910 <at> debbugs.gnu.org" <75910 <at> debbugs.gnu.org>,
 Stefan Monnier <monnier <at> iro.umontreal.ca>
Subject: Re: [External] : bug#75910: 31; Deprecate
 minibuffer-completing-file-name
Date: Tue, 28 Jan 2025 18:19:41 +0100

Drew Adams <drew.adams <at> oracle.com> writes:

>> I propose to deprecate `minibuffer-completing-file-name', since the
>> completion category as part of the completion metadata acts as
>> generalization for this variable. Similarly `minibuffer-completing-
>> symbols' has been deprecated and removed a while ago.
>> 
>> Instead of checking `minibuffer-completing-file-name' one can use
>> (minibuffer-category-p 'file) given the following predicate function:
>> 
>> (defun minibuffer-category-p (cat)
>>   (eq (completion-metadata-get
>>        (completion-metadata
>>         (buffer-substring-no-properties
>>          (minibuffer-prompt-end) (point))
>>         minibuffer-completion-table
>>         minibuffer-completion-predicate)
>>        'category)
>>       cat))
>
> That you don't use something isn't evidence
> that it isn't used.

The variable is not widely used. You can grep the Emacs code base. Also
the completion category metadata has been designed as a general
replacement. I think it should be removed like
`minibuffer-completing-symbol' which has already been removed.

Daniel

Message #14 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>,
 Stefan Monnier <monnier <at> iro.umontreal.ca>
Subject: RE: [External] : bug#75910: 31; Deprecate
 minibuffer-completing-file-name
Date: Tue, 28 Jan 2025 17:29:41 +0000

> I think it should be removed like
> `minibuffer-completing-symbol' which has already been removed.

That variable shouldn't have been removed either.

Checking the Emacs code base isn't relevant for knowing whether or how something is used.  Elisp code is much wider than the Emacs code base.

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

From: Daniel Mendler <mail <at> daniel-mendler.de>
To: Drew Adams <drew.adams <at> oracle.com>
Cc: "75910 <at> debbugs.gnu.org" <75910 <at> debbugs.gnu.org>,
 Stefan Monnier <monnier <at> iro.umontreal.ca>
Subject: Re: bug#75910: 31; Deprecate minibuffer-completing-file-name
Date: Tue, 28 Jan 2025 18:33:43 +0100

Drew Adams <drew.adams <at> oracle.com> writes:

>> I think it should be removed like
>> `minibuffer-completing-symbol' which has already been removed.
>
> That variable shouldn't have been removed either.

Well, we disagree here.

> Checking the Emacs code base isn't relevant for knowing whether or how
> something is used. Elisp code is much wider than the Emacs code base.

Of course. But the completion category as a sufficient replacement is
available already. Deprecation does not imply immediate removal.

Daniel

Message #20 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>,
 Stefan Monnier <monnier <at> iro.umontreal.ca>
Subject: RE: [External] : Re: bug#75910: 31; Deprecate
 minibuffer-completing-file-name
Date: Tue, 28 Jan 2025 18:35:20 +0000

> Deprecation does not imply immediate removal.

Correct.

It doesn't even imply any removal.  It implies
the possibility of removal.  It's a heads-up
that the thing might be removed (desupported)
at some point.

But you spoke of removal.  I object to removal.
I don't object to indefinite deprecation.

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

From: Stefan Kangas <stefankangas <at> gmail.com>
To: Drew Adams <drew.adams <at> oracle.com>, Daniel Mendler <mail <at> daniel-mendler.de>
Cc: "75910 <at> debbugs.gnu.org" <75910 <at> debbugs.gnu.org>,
 Stefan Monnier <monnier <at> iro.umontreal.ca>
Subject: Re: bug#75910: 31; Deprecate minibuffer-completing-file-name
Date: Tue, 28 Jan 2025 13:34:49 -0600

Drew Adams via "Bug reports for GNU Emacs, the Swiss army knife of text
editors" <bug-gnu-emacs <at> gnu.org> writes:

>> I think it should be removed like
>> `minibuffer-completing-symbol' which has already been removed.
>
> That variable shouldn't have been removed either.

It is well-known that you are against ever removing anything, on
principle.

We use different criteria.

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

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Daniel Mendler <mail <at> daniel-mendler.de>
Cc: 75910 <at> debbugs.gnu.org
Subject: Re: bug#75910: 31; Deprecate minibuffer-completing-file-name
Date: Tue, 28 Jan 2025 16:24:07 -0500

> I propose to deprecate `minibuffer-completing-file-name', since the
> completion category as part of the completion metadata acts as
> generalization for this variable. Similarly `minibuffer-completing-symbols'
> has been deprecated and removed a while ago.

+1

[ That's always been the intention behind the `category` property.  ]


        Stefan

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

From: Drew Adams <drew.adams <at> oracle.com>
To: Stefan Kangas <stefankangas <at> gmail.com>, Daniel Mendler
 <mail <at> daniel-mendler.de>
Cc: "75910 <at> debbugs.gnu.org" <75910 <at> debbugs.gnu.org>,
 Stefan Monnier <monnier <at> iro.umontreal.ca>
Subject: RE: [External] : Re: bug#75910: 31; Deprecate
 minibuffer-completing-file-name
Date: Tue, 28 Jan 2025 21:45:42 +0000

> >> I think it should be removed like
> >> `minibuffer-completing-symbol' which has already been removed.
> >
> > That variable shouldn't have been removed either.
> 
> It is well-known that you are against ever
> removing anything, on principle.

(Here we go again with the knee-jerk ad hominem...)

Whether or not you think that's "well-known",
it's incorrect. 

> We use different criteria.

Can you even say what specific criteria were used
to justify removing that variable?  Non-rhetorical
question.

Whether and how much something might still be used
in the Emacs core base itself is an awful yardstick
with which to try to judge its use in the larger
Emacs world.

The Emacs "code base" can, and does, often not try
hard to remain compatible with older code-base code.
Emacs code in the large is a different story.

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

From: Daniel Mendler <mail <at> daniel-mendler.de>
To: Drew Adams <drew.adams <at> oracle.com>
Cc: "75910 <at> debbugs.gnu.org" <75910 <at> debbugs.gnu.org>,
 Stefan Kangas <stefankangas <at> gmail.com>,
 Stefan Monnier <monnier <at> iro.umontreal.ca>
Subject: Re: [External] : Re: bug#75910: 31; Deprecate
 minibuffer-completing-file-name
Date: Tue, 28 Jan 2025 22:56:30 +0100

Drew Adams <drew.adams <at> oracle.com> writes:

> The Emacs "code base" can, and does, often not try
> hard to remain compatible with older code-base code.
> Emacs code in the large is a different story.

So where do you use these variables and why is it not possible to
replace them with a completion category in your packages? I use
`minibuffer-completing-file-name' in my packages too, but I can replace
the variable with the file category without downsides.

Daniel

Message #35 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>,
 Stefan Kangas <stefankangas <at> gmail.com>,
 Stefan Monnier <monnier <at> iro.umontreal.ca>
Subject: RE: [External] : Re: bug#75910: 31; Deprecate
 minibuffer-completing-file-name
Date: Tue, 28 Jan 2025 22:51:19 +0000

> > The Emacs "code base" can, and does, often not try
> > hard to remain compatible with older code-base code.
> > Emacs code in the large is a different story.
> 
> So where do you use these variables and why is it not possible to
> replace them with a completion category in your packages? I use
> `minibuffer-completing-file-name' in my packages too, but I can replace
> the variable with the file category without downsides.

I didn't say that I use them.  I spoke generally,
about Emacs code beyond the Emacs "code base", and
a willy-nilly desire to remove code that such code
can depend on.

I do happen to use them, but that's irrelevant to
the general argument and my objection.  (It just
means some more maintenance time, to enable code to
work with both new and old Emacs releases - nothing
new about that.)

Software producers who have lots of customers/users,
and who don't want to lose them, tend to care about
such code and avoid desupporting it, even if that
might mean a (usually slight) maintenance burden
(slight because no new development of that code, and
often not even bug fixes for it).  Deprecating is a
different matter, and it's not unheard of to see an
explicit, sometimes even announced, intention to
_never_ desupport some particular thing that's
deprecated.

Contrast that with a startup that has few users and
is fine with just moving fast and breaking things,
including for its users/customers.

Emacs has _lots_ of users, and lots who write Elisp
code.  And lots who share such code, in their orgs
or beyond.  And some of them, and some of their own
users, use old Emacs releases.  Lots of users who
never interact with Emacs Dev, never file bugs,
never bother with Reddit, Stack Exchange, or other
Emacs get-together places.

They just _use_ Emacs, and maybe Elisp, like you
use a power cord.  Don't change your wall-plug
design incompatibly without good reasons.  It's
often not a big burden to deprecate (and not
document), and yet keep compatibility/support.

Not changing Elisp constructs willy nilly should
be as ingrained a tendency as not changing default
key bindings.  Support Elisp users like you support
non-Lisper users.  Similarly, put more thought into
new constructs, with an eye to their possible
longevity.

Gnu Emacs & Elisp have four decades and counting.
And a long life ahead yet.

Oh and FWIW, I was the one who suggested/requested
that such a completion `category' thing be added.

So long ago that I'd forgotten about that when
Stefan M. added it much later (also long ago) and
mentioned it.  I'm not against progress.  I'm
against hindering Emacs/Elisp users (not just
code-base maintainers/developers).

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

From: Daniel Mendler <mail <at> daniel-mendler.de>
To: Drew Adams <drew.adams <at> oracle.com>
Cc: "75910 <at> debbugs.gnu.org" <75910 <at> debbugs.gnu.org>,
 Stefan Kangas <stefankangas <at> gmail.com>,
 Stefan Monnier <monnier <at> iro.umontreal.ca>
Subject: Re: [External] : Re: bug#75910: 31; Deprecate
 minibuffer-completing-file-name
Date: Wed, 29 Jan 2025 08:53:01 +0100

Drew Adams <drew.adams <at> oracle.com> writes:

>> > The Emacs "code base" can, and does, often not try
>> > hard to remain compatible with older code-base code.
>> > Emacs code in the large is a different story.
>> 
>> So where do you use these variables and why is it not possible to
>> replace them with a completion category in your packages? I use
>> `minibuffer-completing-file-name' in my packages too, but I can replace
>> the variable with the file category without downsides.
>
> I didn't say that I use them.  I spoke generally,
> about Emacs code beyond the Emacs "code base", and
> a willy-nilly desire to remove code that such code
> can depend on.
>
> I do happen to use them, but that's irrelevant to
> the general argument and my objection.  (It just
> means some more maintenance time, to enable code to
> work with both new and old Emacs releases - nothing
> new about that.)

I do not disagree with the general argument about longevity and
retaining compatibility. Deprecation should be a long process.

But then given that there is a more general mechanism in place, even at
your suggestion, I wonder how you think that adoption of this newer
mechanism should happen. Deprecation of the old mechanism can be used as
signal that something new is available. But you would still preserve
every old mechanism indefinitely?

I consider the accretion of replicated code a problem. In this case, we
are talking about only a little amount. Nevertheless it will make the
API harder to use and understand if multiple mechanisms for the same
thing are present. I also care about good integration of subsystems.
When a new subsystem is added to Emacs, which overlaps with an older
subsystem and aims to replace it, it will lead to indirection via an
adapter and accumulated maintenance burden if old code is kept
indefinitely. It is up to the maintainers to decide where to draw the
line.

Daniel

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

From: Michael Albinus <michael.albinus <at> gmx.de>
To: Daniel Mendler <mail <at> daniel-mendler.de>
Cc: "75910 <at> debbugs.gnu.org" <75910 <at> debbugs.gnu.org>,
 Stefan Monnier <monnier <at> iro.umontreal.ca>, Drew Adams <drew.adams <at> oracle.com>
Subject: Re: bug#75910: 31; Deprecate minibuffer-completing-file-name
Date: Wed, 29 Jan 2025 09:09:14 +0100

Daniel Mendler <mail <at> daniel-mendler.de> writes:

Hi Daniel,

>>> I propose to deprecate `minibuffer-completing-file-name', since the
>>> completion category as part of the completion metadata acts as
>>> generalization for this variable. Similarly `minibuffer-completing-
>>> symbols' has been deprecated and removed a while ago.
>>>
>>> Instead of checking `minibuffer-completing-file-name' one can use
>>> (minibuffer-category-p 'file) given the following predicate function:
>>>
>>> (defun minibuffer-category-p (cat)
>>>   (eq (completion-metadata-get
>>>        (completion-metadata
>>>         (buffer-substring-no-properties
>>>          (minibuffer-prompt-end) (point))
>>>         minibuffer-completion-table
>>>         minibuffer-completion-predicate)
>>>        'category)
>>>       cat))
>>
>> That you don't use something isn't evidence
>> that it isn't used.
>
> The variable is not widely used. You can grep the Emacs code base.

This variable is essential for Tramp method / user name / host name completion.

> Also the completion category metadata has been designed as a general
> replacement. I think it should be removed like
> `minibuffer-completing-symbol' which has already been removed.

The function above doesn't exist (yet). And we will run into the
backward compatibility circus then.

I don't understand what's the glaring argument for removing that
variable. IIRC, it was requested already a while ago, and this was
rejected. What's the change now for doing so?

> Daniel

Best regards, Michael.

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

From: Daniel Mendler <mail <at> daniel-mendler.de>
To: Michael Albinus <michael.albinus <at> gmx.de>
Cc: "75910 <at> debbugs.gnu.org" <75910 <at> debbugs.gnu.org>,
 Stefan Monnier <monnier <at> iro.umontreal.ca>, Drew Adams <drew.adams <at> oracle.com>
Subject: Re: bug#75910: 31; Deprecate minibuffer-completing-file-name
Date: Wed, 29 Jan 2025 09:17:28 +0100

Michael Albinus <michael.albinus <at> gmx.de> writes:

> I don't understand what's the glaring argument for removing that
> variable. IIRC, it was requested already a while ago, and this was
> rejected. What's the change now for doing so?

Can you please point to the relevant discussion? The last time I have
talked with Stefan Monnier about this variable, the plan was still to
deprecate this variable in the longer term, with the goal of use the
completion category as a unifying mechanism.

>> Daniel
>
> Best regards, Michael.

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

From: Michael Albinus <michael.albinus <at> gmx.de>
To: Daniel Mendler <mail <at> daniel-mendler.de>
Cc: "75910 <at> debbugs.gnu.org" <75910 <at> debbugs.gnu.org>,
 Stefan Monnier <monnier <at> iro.umontreal.ca>, Drew Adams <drew.adams <at> oracle.com>
Subject: Re: bug#75910: 31; Deprecate minibuffer-completing-file-name
Date: Wed, 29 Jan 2025 13:10:17 +0100

Daniel Mendler <mail <at> daniel-mendler.de> writes:

Hi Daniel,

>> I don't understand what's the glaring argument for removing that
>> variable. IIRC, it was requested already a while ago, and this was
>> rejected. What's the change now for doing so?
>
> Can you please point to the relevant discussion? The last time I have
> talked with Stefan Monnier about this variable, the plan was still to
> deprecate this variable in the longer term, with the goal of use the
> completion category as a unifying mechanism.

Unfortunately, I cannot find the discussion just now.

But the question remains: What is the benefit removing (deprecating)
this variable?

Furthermore, I don't know the mechanism of completion categories. Is it
guaranteed, that it also works when we're not inside read-file-name? The
advantage of minibuffer-completing-file-name is, that it alwas returns
nil or non-nil, even if there's no active file name completion. Tramp
would require a similar indication, being called inside any completion,
or not. Your proposed replacement, minibuffer-category-p, seems to check
the contents of the minibuffer, which is not relevant for Tramp in general.

>>> Daniel

Best regards, Michael.

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

From: Daniel Mendler <mail <at> daniel-mendler.de>
To: Michael Albinus <michael.albinus <at> gmx.de>
Cc: "75910 <at> debbugs.gnu.org" <75910 <at> debbugs.gnu.org>,
 Stefan Monnier <monnier <at> iro.umontreal.ca>, Drew Adams <drew.adams <at> oracle.com>
Subject: Re: bug#75910: 31; Deprecate minibuffer-completing-file-name
Date: Wed, 29 Jan 2025 15:17:30 +0100

Michael Albinus <michael.albinus <at> gmx.de> writes:

> Daniel Mendler <mail <at> daniel-mendler.de> writes:
>
> Hi Daniel,
>
>>> I don't understand what's the glaring argument for removing that
>>> variable. IIRC, it was requested already a while ago, and this was
>>> rejected. What's the change now for doing so?
>>
>> Can you please point to the relevant discussion? The last time I have
>> talked with Stefan Monnier about this variable, the plan was still to
>> deprecate this variable in the longer term, with the goal of use the
>> completion category as a unifying mechanism.
>
> But the question remains: What is the benefit removing (deprecating)
> this variable?

The completion category mechanism is a generalization of various old
`minibuffer-completing-*' variables. Completion tables like the file
completion table already provide the category, so
`minibuffer-completing-file-name' is a redundancy. 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. The completion
metadata including the category does not have this problem. Furthermore
completion tables can specify categories per completion field. This
means that the category can change during completion, for example when
completing $environment variables as part of a path. In this sense, the
category is more precise. The completion category is used at various
places in the completion machinery and enables the user to customize
behavior per completion category. See for example the customization
variable `completion-category-overrides'. These features and advantages
are not offered by the old `minibuffer-completing-*' variables, and
these are the reasons for the addition of the category mechanism as I
understand. 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.

> Furthermore, I don't know the mechanism of completion categories. Is it
> guaranteed, that it also works when we're not inside read-file-name? The
> advantage of minibuffer-completing-file-name is, that it alwas returns
> nil or non-nil, even if there's no active file name completion. Tramp
> would require a similar indication, being called inside any completion,
> or not. Your proposed replacement, minibuffer-category-p, seems to check
> the contents of the minibuffer, which is not relevant for Tramp in general.

If `minibuffer-completing-file-name' becomes deprecated, a working
alternative should be provided, which works properly for all current
uses of `minibuffer-completing-file-name', even outside the minibuffer.
My `minibuffer-category-p' suggestion was a draft only. It might be
beneficial to offer a more reusable function `minibuffer-category' which
returns the category, or even a function `minibuffer-metadata-get'.
Outside of the minibuffer the functions would return nil. Instead of
checking `minibuffer-completing-file-name', one could check (eq 'file
(minibuffer-category)).

(defun minibuffer-category ()
  (and minibuffer-completion-table
       (completion-metadata-get
        (completion-metadata
         (buffer-substring-no-properties
          (minibuffer-prompt-end) (point))
         minibuffer-completion-table
         minibuffer-completion-predicate)
        'category)))

(defun minibuffer-metadata-get (prop)
  (and minibuffer-completion-table
       (completion-metadata-get
        (completion-metadata
         (buffer-substring-no-properties
          (minibuffer-prompt-end) (point))
         minibuffer-completion-table
         minibuffer-completion-predicate)
        prop)))

Daniel

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

From: Michael Albinus <michael.albinus <at> gmx.de>
To: Daniel Mendler <mail <at> daniel-mendler.de>
Cc: "75910 <at> debbugs.gnu.org" <75910 <at> debbugs.gnu.org>,
 Stefan Monnier <monnier <at> iro.umontreal.ca>, Drew Adams <drew.adams <at> oracle.com>
Subject: Re: bug#75910: 31; Deprecate minibuffer-completing-file-name
Date: Wed, 29 Jan 2025 15:30:19 +0100

Daniel Mendler <mail <at> daniel-mendler.de> writes:

Hi Daniel,

> If `minibuffer-completing-file-name' becomes deprecated, a working
> alternative should be provided, which works properly for all current
> uses of `minibuffer-completing-file-name', even outside the
> minibuffer.

I take your word, that you inject this alternative into the Tramp
sources. It must be backward compatible down to Emacs 28.

> Daniel

Best regards, Michael.

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

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
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>, Drew Adams <drew.adams <at> oracle.com>
Subject: Re: bug#75910: 31; Deprecate minibuffer-completing-file-name
Date: Wed, 29 Jan 2025 10:57:48 -0500

>>>> I don't understand what's the glaring argument for removing that
>>>> variable. IIRC, it was requested already a while ago, and this was
>>>> rejected. What's the change now for doing so?
>>>
>>> Can you please point to the relevant discussion? The last time I have
>>> talked with Stefan Monnier about this variable, the plan was still to
>>> deprecate this variable in the longer term, with the goal of use the
>>> completion category as a unifying mechanism.
>>
>> But the question remains: What is the benefit removing (deprecating)
>> this variable?
>
> The completion category mechanism is a generalization of various old
> `minibuffer-completing-*' variables. Completion tables like the file
> completion table already provide the category, so
> `minibuffer-completing-file-name'

I think there's a bit of misunderstanding here: IIUC Tramp's use of
`minibuffer-completing-file-name` is not to check "what are we
completing?" but rather to check "are we completing?".
IOW, it's (ab)using that variable to distinguish the case where Tramp is
used as part of a completion, as opposed to something else.

IOW, we should clarify exactly what those tests of
`minibuffer-completing-file-name` actually aim to do, in Tramp's code,
before we can figure out what to replace them with.


        Stefan

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

From: Daniel Mendler <mail <at> daniel-mendler.de>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: "75910 <at> debbugs.gnu.org" <75910 <at> debbugs.gnu.org>,
 Michael Albinus <michael.albinus <at> gmx.de>, Drew Adams <drew.adams <at> oracle.com>
Subject: Re: bug#75910: 31; Deprecate minibuffer-completing-file-name
Date: Wed, 29 Jan 2025 17:29:03 +0100

Stefan Monnier <monnier <at> iro.umontreal.ca> writes:

>>>>> I don't understand what's the glaring argument for removing that
>>>>> variable. IIRC, it was requested already a while ago, and this was
>>>>> rejected. What's the change now for doing so?
>>>>
>>>> Can you please point to the relevant discussion? The last time I have
>>>> talked with Stefan Monnier about this variable, the plan was still to
>>>> deprecate this variable in the longer term, with the goal of use the
>>>> completion category as a unifying mechanism.
>>>
>>> But the question remains: What is the benefit removing (deprecating)
>>> this variable?
>>
>> The completion category mechanism is a generalization of various old
>> `minibuffer-completing-*' variables. Completion tables like the file
>> completion table already provide the category, so
>> `minibuffer-completing-file-name'
>
> I think there's a bit of misunderstanding here: IIUC Tramp's use of
> `minibuffer-completing-file-name` is not to check "what are we
> completing?" but rather to check "are we completing?".
> IOW, it's (ab)using that variable to distinguish the case where Tramp is
> used as part of a completion, as opposed to something else.

To be clear, I have not checked every occurrence of the variable, only
that it is used rarely and that the completion category is an
alternative mechanism which can be used as an adequate substitute if we
want to know the type of completion. Otherwise I would have sent a patch
already. If we only want to check if completion is active we can check
other variables.

> IOW, we should clarify exactly what those tests of
> `minibuffer-completing-file-name` actually aim to do, in Tramp's code,
> before we can figure out what to replace them with.

Of course. Again, my proposal of minibuffer-category-p was only a draft
and not a patch. For me the question here is if deprecation of the
variable should be pursued or not.

>         Stefan

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

From: Michael Albinus <michael.albinus <at> gmx.de>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: Daniel Mendler <mail <at> daniel-mendler.de>, Drew Adams <drew.adams <at> oracle.com>,
 "75910 <at> debbugs.gnu.org" <75910 <at> debbugs.gnu.org>
Subject: Re: bug#75910: 31; Deprecate minibuffer-completing-file-name
Date: Wed, 29 Jan 2025 17:41:55 +0100

Stefan Monnier <monnier <at> iro.umontreal.ca> writes:

Hi Stefan,

> I think there's a bit of misunderstanding here: IIUC Tramp's use of
> `minibuffer-completing-file-name` is not to check "what are we
> completing?" but rather to check "are we completing?".
> IOW, it's (ab)using that variable to distinguish the case where Tramp is
> used as part of a completion, as opposed to something else.
>
> IOW, we should clarify exactly what those tests of
> `minibuffer-completing-file-name` actually aim to do, in Tramp's code,
> before we can figure out what to replace them with.

Agreed.

Just as a matter of fact, when I've introduced
minibuffer-completing-file-name into Tramp, I had to set it somewhere
else as well. For example let-binding tramp-mode, non-essential and
minibuffer-completing-file-name in pcomplete--entries, but I don't
remember the details.

>         Stefan

Best regards, Michael.

Message #65 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>, Michael Albinus
 <michael.albinus <at> gmx.de>
Cc: "75910 <at> debbugs.gnu.org" <75910 <at> debbugs.gnu.org>,
 Stefan Monnier <monnier <at> iro.umontreal.ca>
Subject: RE: [External] : Re: bug#75910: 31; Deprecate
 minibuffer-completing-file-name
Date: Wed, 29 Jan 2025 20:10:12 +0000

> The completion category mechanism is a generalization of various old
> `minibuffer-completing-*' variables. Completion tables like the file
> completion table already provide the category, so
> `minibuffer-completing-file-name' is a redundancy. 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.

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

> Furthermore
> completion tables can specify categories per completion field. This
> means that the category can change during completion, for example when
> completing $environment variables as part of a path. In this sense,
> the category is more precise. 

Yes.

> The completion category is used at various
> places in the completion machinery and enables the user to customize
> behavior per completion category. See for example the customization
> variable `completion-category-overrides'. These features and advantages
> are not offered by the old `minibuffer-completing-*' variables, and
> these are the reasons for the addition of the category mechanism as I
> understand. 

Agreed.

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

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

From: Daniel Mendler <mail <at> daniel-mendler.de>
To: Drew Adams <drew.adams <at> oracle.com>
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: Wed, 29 Jan 2025 22:43:24 +0100

Drew Adams <drew.adams <at> oracle.com> writes:

>> The completion category mechanism is a generalization of various old
>> `minibuffer-completing-*' variables. Completion tables like the file
>> completion table already provide the category, so
>> `minibuffer-completing-file-name' is a redundancy. 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. 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. It is an argument in favor of deprecating the
variable, if the variable can easily be used incorrectly.

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

Daniel

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

From: Björn Bidar <bjorn.bidar <at> thaodan.de>
To: Daniel Mendler via "Bug reports for GNU Emacs, the Swiss army knife of
 text editors" <bug-gnu-emacs <at> gnu.org>
Cc: Daniel Mendler <mail <at> daniel-mendler.de>,
 Michael Albinus <michael.albinus <at> gmx.de>,
 Stefan Monnier <monnier <at> iro.umontreal.ca>, Drew Adams <drew.adams <at> oracle.com>,
 "75910 <at> debbugs.gnu.org" <75910 <at> debbugs.gnu.org>
Subject: Re: bug#75910: 31; Deprecate minibuffer-completing-file-name
Date: Thu, 30 Jan 2025 08:51:13 +0200

Daniel Mendler via "Bug reports for GNU Emacs, the Swiss army knife of
text editors" <bug-gnu-emacs <at> gnu.org> writes:

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

Would it be better to first a discussion on what to transition too
before talking about deprecation of this variable?

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Björn Bidar <bjorn.bidar <at> thaodan.de>
Cc: 75910 <at> debbugs.gnu.org, michael.albinus <at> gmx.de, monnier <at> iro.umontreal.ca,
 drew.adams <at> oracle.com, mail <at> daniel-mendler.de
Subject: Re: bug#75910: 31; Deprecate minibuffer-completing-file-name
Date: Thu, 30 Jan 2025 09:21:12 +0200

> Cc: mail <at> daniel-mendler.de, michael.albinus <at> gmx.de, monnier <at> iro.umontreal.ca,
>  drew.adams <at> oracle.com
> Date: Thu, 30 Jan 2025 08:51:13 +0200
> From:  Björn Bidar via "Bug reports for GNU Emacs,
>  the Swiss army knife of text editors" <bug-gnu-emacs <at> gnu.org>
> 
> Daniel Mendler via "Bug reports for GNU Emacs, the Swiss army knife of
> text editors" <bug-gnu-emacs <at> gnu.org> writes:
> 
> > 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.
> 
> Would it be better to first a discussion on what to transition too
> before talking about deprecation of this variable?

That was already stated in the original report.  If you have some
comments to that proposal, please tell.

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.

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

From: Daniel Mendler <mail <at> daniel-mendler.de>
To: Drew Adams <drew.adams <at> oracle.com>
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 18:46:25 +0100

Drew Adams <drew.adams <at> oracle.com> writes:

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

No, I really mean almost always. One does not want some variable setting
which is meant to affect a certain outer completion session to also
affect arbitrary other nested completion sessions, which are started by
the user.

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.

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

Nevertheless it makes sense to minimize the occurrence of problematic
constructs if we have better tools available. We simply disagree about
this matter.

Daniel

Message #86 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 18:00:04 +0000

> >> 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".
> 
> No, I really mean almost always. 

Sure you do.  But what you also said was that
_I_ said _I_ mean that too.  And that's _not_
what I said.

> One does not want some variable setting
> which is meant to affect a certain outer completion session to also
> affect arbitrary other nested completion sessions, which are started by
> the user.

"One" -> you.

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

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

From: Daniel Mendler <mail <at> daniel-mendler.de>
To: Drew Adams <drew.adams <at> oracle.com>
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 19:07:03 +0100

Drew Adams <drew.adams <at> oracle.com> writes:

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

Daniel

Message #92 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 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)...)

Previous Next

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