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

From: Daniel Mendler <[email-masked]>
Date: Wed, 29 Jan 2025 08:53:01 +0100

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