bug#75306: 31.0.50; Make `small-temporary-file-directory` variable obsolete

[Eli Zaretskii <eliz@gnu.org>]

> From: Stefan Kangas <stefankangas@gmail.com>
> Date: Fri, 3 Jan 2025 03:15:49 -0600
> Cc: 75306@debbugs.gnu.org
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > This says nothing about MS-DOS,
> 
> The docstring is one thing, but the variable _definition_ reads the same
> today as when it was first introduced (in ffc0e1caf1a6):
> 
> (defvar small-temporary-file-directory
>   (if (eq system-type 'ms-dos) (getenv "TMPDIR"))
> 
> This makes it clear that the intention was, at least in part, to support
> MS-DOS specifically, and it has remained that over the years.

no, the _default_value_ caters to MS-DOS specifically.  But that
doesn't yet mean the variable itself is for that system.

> I doubt that this micro-optimization (or whatever we should call it) is
> likely to give much bang for your buck, especially not in an age when
> users are starting to routinely throw 500 MiB or even 1 GiB at their
> tmpfs RAM disks.

Maybe so, but we had this variable for eons, and I can easily imagine
valid use cases for it even today.  For example, some system whose
disks are of different speed (say, SSD and spinning disk).

> > But if some user has a good reason to customize this, why take that
> > flexibility from them?  How do we justify removal of a feature which
> > could be useful to someone?
> 
> Besides the Tramp use case (which is valid and deserves its own
> variable), it is used only in some very old modules: vc-rcs.el and
> cmacexp.el, in shell-command-on-region, and literally nowhere else.

Except by an unknown number of users.  Why break their setup?

> I do agree that there's no compelling reason why we must remove _this
> particular piece of cruft_ specifically, but I also don't see any good
> reason to keep it.

We should only remove or obsolete existing features if we have a good
reason for that.  A valid, and a very good, reason to keep a feature
is that we already have it.