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

Previous Next

Full log

View this message in rfc822 format

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

Previous Next

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