problems viewing attachments in emacs ui
Austin Clements
amdragon at MIT.EDU
Wed Jul 31 07:55:09 PDT 2013
Quoth myself on Jul 30 at 10:53 pm:
> Quoth Jameson Graef Rollins on Jul 28 at 10:06 am:
> > On Sun, Jul 28 2013, Jameson Graef Rollins <jrollins at finestructure.net> wrote:
> > > For instance, if I launch notmuch-show-view-part on an html part, my
> > > browser opens pointed at e.g. the following file:
> > >
> > > file:///home/jrollins/tmp/emm.610040w/mm.6100F_2.htm
> > >
> > > But the browser shows the following error:
> > >
> > > File not found
> > > Iceweasel can't find the file at /home/jrollins/tmp/emm.610040w/mm.6100F_2.htm.
> >
> > I'm now realizing that my problem with html parts is probably that
> > browser is attempting to open the temporary file in the background.
> > When the browser call returns, the caller assumes the application is
> > done with the temp file and purges it. So for this issue at least I
> > need to either convince my browser to not open the file in the
> > background, or tell emacs to cleanup temp files at some later time
> > (session termination, for instance).
>
> As pointed out by David, the root of this problem is in
> mm-display-external in mm-decode.el. mm-display-external was mostly
> rewritten between Emacs 24.1 and Emacs 24.2 (Emacs commit 1354a694).
> The Emacs 24.1 implementation would wait for the spawned process to
> exit or 30 seconds to elapse, whichever was longer, before deleting
> the file (Emacs 23 was much the same, but waited only 2 seconds).
> Based on the source comments, this appears to be the *intent* of the
> Emacs 24.2 implementation, but what the code actually does is to wait
> for whichever of these events happens *first*. So, if the spawned
> process exits immediately (like in your situation), the file will be
> deleted immediately, and even if the viewer sticks around, the file
> will be deleted after 30 seconds anyway.
>
> This must be affecting Gnus users the same way, but I haven't found
> any evidence that they're aware of it. The mm-display-external code
> still has this problem in both the current Emacs master and the
> current Gnus master.
Try this patch to mm-decode.el. It should restore the original
behavior and intent of mm-display-external (in a much less gruesome
way than the old 24.1 code). I simply copied mm-decode.el into my
personal elisp directory (which appears early in my load-path), which
seemed to work just fine for my cursory testing.
diff --git a/lisp/gnus/mm-decode.el b/lisp/gnus/mm-decode.el
index 98be1c5..c11790c 100644
--- a/lisp/gnus/mm-decode.el
+++ b/lisp/gnus/mm-decode.el
@@ -958,26 +958,30 @@ external if displayed external."
shell-command-switch command)
(set-process-sentinel
(get-buffer-process buffer)
- (lexical-let ((outbuf outbuf)
- (file file)
- (buffer buffer)
- (command command)
- (handle handle))
+ (lexical-let* ((outbuf outbuf)
+ (file file)
+ (buffer buffer)
+ (command command)
+ (handle handle)
+ (timer-fired nil)
+ (proc-exited nil)
+ (maybe-cleanup
+ (lambda ()
+ (when (and timer-fired proc-exited)
+ (ignore-errors
+ (delete-file file))
+ (ignore-errors
+ (delete-directory
+ (file-name-directory file)))))))
(run-at-time
30.0 nil
(lambda ()
- (ignore-errors
- (delete-file file))
- (ignore-errors
- (delete-directory (file-name-directory file)))))
+ (setq timer-fired t)
+ (funcall maybe-cleanup)))
(lambda (process state)
(when (eq (process-status process) 'exit)
- (condition-case nil
- (delete-file file)
- (error))
- (condition-case nil
- (delete-directory (file-name-directory file))
- (error))
+ (setq proc-exited t)
+ (funcall maybe-cleanup)
(when (buffer-live-p outbuf)
(with-current-buffer outbuf
(let ((buffer-read-only nil)
More information about the notmuch
mailing list