Date: Wed, 31 Jul 2013 11:05:31 -0400
From: Austin Clements <amdragon@MIT.EDU>
To: Jameson Graef Rollins <jrollins@finestructure.net>
Subject: Re: problems viewing attachments in emacs ui
Message-ID: <20130731150531.GX2214@mit.edu>
References: <87hafe4ox6.fsf@servo.finestructure.net>
	<87ehai4ns3.fsf@servo.finestructure.net>
	<20130731025303.GV2214@mit.edu>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20130731025303.GV2214@mit.edu>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: notmuch@notmuchmail.org
Precedence: list

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@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.

I dug into the Gnus repository to find the original source of this
change.  For those who are curious, it's commit dce35658 from Feb. 9,
2012.  Interestingly, the commit message is

    Output text from external commands in the article buffer
    
    * gnus-compat.el: Define `timer-set-function'.
    
    * mm-decode.el (mm-display-external): Output the text from the command
    in the buffer after the command finished.  This makes text-based
    commands behave better.

which says nothing about the complete restructuring of the timer
handling, which further reinforces my suspicion that the behavioral
change was unintentional.