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

[Stefan Kangas <stefankangas@gmail.com>]

Eli Zaretskii <eliz@gnu.org> writes:

>> Cc: 75306@debbugs.gnu.org
>> Date: Fri, 03 Jan 2025 06:56:03 +0100
>> From:  Michael Albinus via "Bug reports for GNU Emacs,
>>  the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>
>>
>> Stefan Kangas <stefankangas@gmail.com> writes:
>>
>> Hi Stefan,
>>
>> > I think the variable doesn't make much sense these days, and should be
>> > made obsolete.  Note that it is barely used in Emacs and third-party
>> > packages.
>> >
>> > However, Tramp recently started using the variable as a place to create
>> > OpenSSH Unix domain sockets.  May I suggest that Tramp uses some other
>> > variable for this purpose, perhaps a Tramp specific one?
>>
>> Is there a reason that it must be changed? What are the advantages? Does
>> it hurt to keep the user option?
>
> Exactly my questions.
>
> The doc string says:
>
>   If non-nil, this directory is used instead of ‘temporary-file-directory’
>   by programs that create small temporary files.  This is for systems that
>   have fast storage with limited space, such as a RAM disk.
>
> 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.

> and makes perfect sense to me.  It gives our users a capability to
> direct small enough temporary files to a fast temporary filesystem ...
> From my POV, this feature needs zero maintenance.

This feature would need maintenance just like any other, but it hasn't
seen too much of that.  If people had taken it seriously, we would have
seen it used it in many more places.

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.  Not everyone, of course, but this has been the general
direction; even low end systems have at minimum an order of magnitude
more resources now than when this variable was introduced 24 years ago.

> 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.
I suspect that it's removal wouldn't be noticed by anyone, even if we
were to assume that someone somewhere is getting slightly better
performance out of RCS/C macro expansions/Shell commands from using this.

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.