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

Previous Next

Full log

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

Previous Next

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