> From: Bruno Haible <br...@clisp.org> > Cc: egg...@cs.ucla.edu, bug-gnulib@gnu.org, la...@gnus.org, > 57...@debbugs.gnu.org, jporterb...@gmail.com > Date: Tue, 16 Aug 2022 19:29:33 +0200 > > > The buffer which visited that file still exists, and still records the > > name of the file, yes. And then, when the program writes to another > > file created by another call to make-temp-file, it actually writes to > > a file that some buffer still visits, and in Emacs that triggers a > > prompt to the user to refresh the buffer. > > That is a reasonable behaviour for a text editor — but only for file > names that are explicitly controlled by some program or by the user, > not for temporary files.
Why not for temporary files? Emacs has a with-temp-file macro, which generates a temporary file name, executes the body of the macro with a variable bound to the file name, then deletes the file. Very handy for writing test suites. We don't usually bother deleting the buffers where the file was processed in those tests, because the test suite runs in batch mode, and Emacs exits after running the tests, thus cleaning up. Having to carefully make sure no such buffers were left from the previous test is a nuisance. > > The programmer didn't > > expect that because it is natural to expect each call to a function > > that creates a temporary file to create a file under a new name, not > > reuse the same name. > > This is an incorrect assumption. Just like socket numbers are randomly > generated in some situations, temp file names are random, and you can't > make assumptions about the resulting file name. People get their ideas from other similar APIs, and functions like tmpfile in C do generate a different name each call. > How about storing, as an attribute of the buffer, a boolean that tells > whether the underlying file name is randomly generated (i.e. a temp file), > and query this boolean before prompting to the user to refresh the buffer? That's a terrible complications, especially since the solution is so close at hand, and it makes gen_tempname behave on Windows as it does on GNU/Linux, and as it behaved just a year or two ago.