Date: Sun, 20 Oct 2013 09:51:32 +0200
From: Andreas Röhler <andreas.roehler@easy-emacs.de>
Cc: 15647@debbugs.gnu.org
IIUC the purpose is to make sure it's erased and to make sure it's
erased *after* the use. Whether it does that, I don't know.
But doing it in Elisp would otherwise require detecting the next prompt
Don't think so. Once the file is sent to process, it's sent.
That's Unix-speak: deleting a file that is potentially in use.
Outside of Posix, deleting a file immediately after submitting it to a
process will at best fail (because the process is still using it), and
at worst cause trouble (because the process didn't yet have enough
time to even open the file).
In fact, in this case, even on Unix this proposal will cause trouble,
because the command sent to Python might take time to execute on the
Python side, and we might already have deleted the file when Python
tries to open it.
I think in this case the better place to delete the file is in
python-shell-send-file, as part of the command sent to Python, because
that's where we know that the file was used up and closed by the
Python interpreter.
A remaining question: what to do if the command fails? Maybe the temp file is
of interest than?
Which might be an argument to do it from Python, as the error might prevent
further action, i.e. deleting.
No, it's an argument to add independent logging facilities to
python.el, IMO. IOW, if python.el wants to have debugging features,
it should have them without relying on the Python interpreter and
without interfering with the "normal" workflow (whereby the file is
deleted after being used). Relying on a temporary file to remain in
the filesystem for prolonged periods of time is not a good idea
anyway.