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

Previous Next

Full log

View this message in rfc822 format

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

Previous Next

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