Subject: bug#75910: 31; Deprecate minibuffer-completing-file-name

From: Daniel Mendler <[email-masked]>
Date: Thu, 30 Jan 2025 18:46:25 +0100

Drew Adams <[email-masked]> 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