MIME parts not saved

MIME parts not saved

[John Williams]

When I try to view an attachement in an email message (a MS Word
document or PDF, for example), Gnus helpfully tells me that xdg-open is
opening /tmp/mm* . But nothing ever happens.  In a sepratate terminal
window I say ls /tmp/mm*, but there are no files of that pattern.

So then I try to save the part locally, am prompted for a location and
save the file.  Great!  The file is created. Except that when I go to
open it, I find that it is empty, i.e. 0 bytes.

I have no clue how to start debugging this. What infomation shouldl I
provide to anyone who would like to help me?  My whole .emacs and/or
.gnus.el?

Ma Gnus v0.17, Emacs 24.3.50.1 on Fedora 19.  Is any other information
relevant?

Thanks,

John

Re: MIME parts not saved

[Lars Magne Ingebrigtsen]

John Williams <john.williams@otago.ac.nz> writes:

> So then I try to save the part locally, am prompted for a location and
> save the file.  Great!  The file is created. Except that when I go to
> open it, I find that it is empty, i.e. 0 bytes.

Is there actually anything in the attachment?

-- 
(domestic pets only, the antidote for overdose, milk.)
  No Gnus T-Shirt for sale: http://ingebrigtsen.no/no.php

Re: MIME parts not saved

[Katsumi Yamaoka]

john.williams@otago.ac.nz wrote:
> When I try to view an attachement in an email message (a MS Word
> document or PDF, for example), Gnus helpfully tells me that xdg-open is
> opening /tmp/mm* . But nothing ever happens.  In a sepratate terminal
> window I say ls /tmp/mm*, but there are no files of that pattern.

For viewing, those are temporary files and will be deleted after
passing them to a viewer.  I had the same problem about xdg-open
and brought it up here years ago:

http://thread.gmane.org/gmane.emacs.gnus.general/68353

The solution I took then was to remove xdg-open from the mailcap
database, as described in the article.  You may want to add the
entries to the database[1] for the pairs of the content-types and
the viewers if Fedora doesn't provide them in the system mailcap
database.  To know what entries there are, do
`M-x load-library RET mailcap RET' and
`C-h v mailcap-mime-data RET'.

[1] An easy way is to have the ~/.mailcap file with the entries
    like the following:

application/pdf; /usr/bin/acroread %s
application/msword; /usr/bin/ooffice %s

    Note that whenever you edited the file you have to do
    `M-x mailcap-parse-mailcaps RET', or restart Emacs and Gnus.

> So then I try to save the part locally, am prompted for a location and
> save the file.  Great!  The file is created. Except that when I go to
> open it, I find that it is empty, i.e. 0 bytes.

I don't know.  Is it always empty for any attachment?

> I have no clue how to start debugging this. What infomation shouldl I
> provide to anyone who would like to help me?  My whole .emacs and/or
> .gnus.el?

As for the case an empty file is saved, forward an example mail
to me if possible.

> Ma Gnus v0.17, Emacs 24.3.50.1 on Fedora 19.  Is any other information
> relevant?

Re: MIME parts not saved

[John Williams]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> John Williams <john.williams@otago.ac.nz> writes:
>
>> So then I try to save the part locally, am prompted for a location and
>> save the file.  Great!  The file is created. Except that when I go to
>> open it, I find that it is empty, i.e. 0 bytes.
>
> Is there actually anything in the attachment?
I'm an idiot.  I forgot that I had set nnimap to only download the
non-MIME parts of each message.

*Hangs head in shame*

Re: MIME parts not saved

[John Williams]

Katsumi Yamaoka <yamaoka@jpl.org> writes:

> The solution I took then was to remove xdg-open from the mailcap
> database, as described in the article.  You may want to add the
> entries to the database[1] for the pairs of the content-types and
> the viewers if Fedora doesn't provide them in the system mailcap
> database.  To know what entries there are, do
> `M-x load-library RET mailcap RET' and
> `C-h v mailcap-mime-data RET'.
>
> [1] An easy way is to have the ~/.mailcap file with the entries
>     like the following:
>
> application/pdf; /usr/bin/acroread %s
> application/msword; /usr/bin/ooffice %s
>
>     Note that whenever you edited the file you have to do
>     `M-x mailcap-parse-mailcaps RET', or restart Emacs and Gnus.
That works great, thank you so much!  But if this is a common problem,
perhaps it should be noted in the Gnus manual, in the section about
dealing with MIME parts?

>> So then I try to save the part locally, am prompted for a location and
>> save the file.  Great!  The file is created. Except that when I go to
>> open it, I find that it is empty, i.e. 0 bytes.
>
> I don't know.  Is it always empty for any attachment?
I forgot that I had set nnimap to only download non-MIME parts from the
server. As soon as Lars asked if there was anything in the attachment, I
remembered. I'm sorry to have bothered you and Lars with this silly
question.

Thanks for your help,

John

Re: MIME parts not saved

[Katsumi Yamaoka]

[-- Attachment #1: Type: text/plain, Size: 680 bytes --]

john.williams@otago.ac.nz wrote:
> But if this is a common problem, perhaps it should be noted in the
> Gnus manual, in the section about dealing with MIME parts?

I was going to improve Gnus so as to run xdg-open but it slipped
my mind someday.  But Google taught me today that someone has
solved it perfectly:

http://i-yt.info/?date=20090829#p01 (Japanese)

One says "To make xdg-open work with `start-process', bind
`process-connection-type' to nil.".  I'll try it on Fedora 19 in
home (now I'm in the office and have Cygwin only) later.  Before
I do it, could someone try the attached patch?  Note that this
should work for not only xdg-open but also any external programs.


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: Type: text/x-patch, Size: 453 bytes --]

--- mm-decode.el~	2013-08-01 22:11:47.000000000 +0000
+++ mm-decode.el	2013-08-05 11:22:29.135609300 +0000
@@ -907,3 +907,4 @@
 	    (let ((command (mm-mailcap-command
-			    method file (mm-handle-type handle))))
+			    method file (mm-handle-type handle)))
+		  (process-connection-type nil))
 	      (unwind-protect
@@ -964,3 +965,3 @@
 	      (unwind-protect
-		  (progn
+		  (let ((process-connection-type nil))
 		    (start-process "*display*"

Re: MIME parts not saved

[Katsumi Yamaoka]

[-- Attachment #1: Type: text/plain, Size: 423 bytes --]

Katsumi Yamaoka <yamaoka@jpl.org> wrote:
> http://i-yt.info/?date=20090829#p01 (Japanese)

> One says "To make xdg-open work with `start-process', bind
> `process-connection-type' to nil.".  I'll try it on Fedora 19 in
> home

I tried it on Fedora 19 and realized there is another problem.
That is, `mm-display-external' deletes a temporary file too early
to let at least xdg-open work.  A temporary solution is attached.


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: Type: text/x-patch, Size: 708 bytes --]

--- mm-decode.el~	2013-08-02 13:27:04.887614207 +0000
+++ mm-decode.el	2013-08-05 15:14:07.063121804 +0000
@@ -964,3 +964,3 @@
 	      (unwind-protect
-		  (progn
+		  (let ((process-connection-type nil))
 		    (start-process "*display*"
@@ -986,8 +986,8 @@
 			 (when (eq (process-status process) 'exit)
-			   (condition-case nil
-			       (delete-file file)
-			     (error))
-			   (condition-case nil
-			       (delete-directory (file-name-directory file))
-			     (error))
+			   ;;(condition-case nil
+			   ;;    (delete-file file)
+			   ;;  (error))
+			   ;;(condition-case nil
+			   ;;    (delete-directory (file-name-directory file))
+			   ;;  (error))
 			   (when (buffer-live-p outbuf)

Re: MIME parts not saved

[Katsumi Yamaoka]

Katsumi Yamaoka <yamaoka@jpl.org> wrote:
>> http://i-yt.info/?date=20090829#p01 (Japanese)

>> One says "To make xdg-open work with `start-process', bind
>> `process-connection-type' to nil.".  I'll try it on Fedora 19 in
>> home

> I tried it on Fedora 19 and realized there is another problem.
> That is, `mm-display-external' deletes a temporary file too early
> to let at least xdg-open work.  A temporary solution is attached.

Now xdg-open should work called by Gnus (hopefully).  Binding of
`process-connection-type' to nil was necessary for at least Fedora
(I don't know why but Cygwin doesn't need it).
The other cause of xdg-open not working was simple; xdg-open has
no sooner launched an external viewer than it finishes, whereas
Gnus deleted a temporary file (before passing it out to the viewer)
as soon as xdg-open finished.

Now a temporary file will be deleted by a timer 10 seconds after
launching xdg-open.  It means that a temporary file will be left
if you kill Emacs within 10 seconds.  Perhaps it might be better
to use `kill-emacs-hook' together or decrease the time to wait.

As for Windows or Cygwin, those temporary file and folder cannot
be deleted while a viewer is running if it is a Windows' app., so
a user may want to delete them periodically.

Re: MIME parts not saved

[Dan Christensen]

Katsumi Yamaoka <yamaoka@jpl.org> writes:

> The other cause of xdg-open not working was simple; xdg-open has
> no sooner launched an external viewer than it finishes, whereas
> Gnus deleted a temporary file (before passing it out to the viewer)
> as soon as xdg-open finished.
>
> Now a temporary file will be deleted by a timer 10 seconds after
> launching xdg-open.

There's already logic to delay deletion in mm-display-external, although
for some reason it is only used in certain situations.  Maybe your
change can be merged with the existing code?

I find that even a 30 second delay is not enough sometimes, as certain
viewers notice the deletion and stop displaying the file.  So I think it
would be convenient to have a variable which indicates that temporary
files should be left forever, to be cleaned up as other files in /tmp
are.

Dan

Re: MIME parts not saved

[Katsumi Yamaoka]

Dan Christensen wrote:
> Katsumi Yamaoka <yamaoka@jpl.org> writes:
>> Now a temporary file will be deleted by a timer 10 seconds after
>> launching xdg-open.

> There's already logic to delay deletion in mm-display-external, although
> for some reason it is only used in certain situations.  Maybe your
> change can be merged with the existing code?

Why I didn't use `mm-postponed-undisplay-list' was that a data
file is made read-only (i.e., not editable) and a viewer doesn't
need the file all the while it is running.  However, given even
a 30 seconds delay is not enough, I think we should not stick to
the speediness of deleting the file.

> I find that even a 30 second delay is not enough sometimes, as
> certain viewers notice the deletion and stop displaying the file.

I can imagin it; even in a fast machine, ooffice or equivalent
takes a long time for starting up.  Moreover, Gnus will never
know what program xdg-open and the like launches nor when the
program finishes.  So, we may have to keep all temporary files
from being deleted.

> So I think it would be convenient to have a variable which indicates
> that temporary files should be left forever, to be cleaned up as
> other files in /tmp are.

Hm, if it is boolean and defaults to nil (deleting), I don't
think a user will find it and alter the value.  Instead, how
about deleting temporary files at the next time Gnus starts?
That is:

o Save a list of files to be deleted in "$TMP/.mm-temp-files" when
  Gnus exits.
o Try to delete those files when Gnus starts.  If it fails on
  deleting of some files, schedule them to delete again.

This way will be helpful also for Emacs on Windows and Cygwin.

Re: MIME parts not saved

[Katsumi Yamaoka]

Katsumi Yamaoka wrote:
> Instead, how about deleting temporary files at the next time
> Gnus starts?  That is:

> o Save a list of files to be deleted in "$TMP/.mm-temp-files" when
>   Gnus exits.
> o Try to delete those files when Gnus starts.  If it fails on
>   deleting of some files, schedule them to delete again.

> This way will be helpful also for Emacs on Windows and Cygwin.

I've installed this.  Now it tries to delete temporary files when
exiting Gnus.  If it fails for a reason something like that a viewer
is still running and catching hold of a file, it schedules the files
left to be deleted at the next time Gnus exits (not Gnus starts).
The file that holds a list of temporary files to be deleted next
time is "$TMP/.mm-temp-files-UserName" (mode 0600).  The deletion
is done by `gnus-exit-gnus-hook'.

Re: MIME parts not saved

[Dan Christensen]

Katsumi Yamaoka <yamaoka@jpl.org> writes:

> Katsumi Yamaoka wrote:
>> Instead, how about deleting temporary files at the next time
>> Gnus starts?  That is:
>
>> o Save a list of files to be deleted in "$TMP/.mm-temp-files" when
>>   Gnus exits.
>> o Try to delete those files when Gnus starts.  If it fails on
>>   deleting of some files, schedule them to delete again.
>
>> This way will be helpful also for Emacs on Windows and Cygwin.
>
> I've installed this.  Now it tries to delete temporary files when
> exiting Gnus. 

Sounds great!  Does this also apply for the files opened using
mm-display-external?

Dan

Re: MIME parts not saved

[Katsumi Yamaoka]

Dan Christensen wrote:
> Katsumi Yamaoka <yamaoka@jpl.org> writes:
>>> Instead, how about deleting temporary files at the next time
>>> Gnus starts?  That is:
>>
>>> o Save a list of files to be deleted in "$TMP/.mm-temp-files" when
>>>   Gnus exits.
>>> o Try to delete those files when Gnus starts.  If it fails on
>>>   deleting of some files, schedule them to delete again.
>>
>>> This way will be helpful also for Emacs on Windows and Cygwin.
>>
>> I've installed this.  Now it tries to delete temporary files when
>> exiting Gnus.

> Sounds great!  Does this also apply for the files opened using
> mm-display-external?

Yes, it does, for the case the mailcap entry specifies neither
`needsterm' nor `copiousoutput'.  In that case, now it tries to
delete temporary files one minutes after launching a viewer and
when Gnus exits[1].  As for the `copiousoutput' case, temp files
will be deleted after a viewer exits.  However, as for the
`needsterm' case, there's no code for the temp files deletion
as it was as before.  I'm going to verify whether it's ok.

[1] The deletion will fail on Windows or Cygwin if a viewer
 is a Windows application, MS Office, AcroRd, etc. for example,
 and is running at that time.

Re: MIME parts not saved

[Katsumi Yamaoka]

Katsumi Yamaoka wrote:
> However, as for the `needsterm' case, there's no code for the temp
> files deletion as it was as before.  I'm going to verify whether
> it's ok.

I confirmed that it needs the temporary files deletion as well.
Done.

Re: MIME parts not saved

[Dan Christensen]

Katsumi Yamaoka <yamaoka@jpl.org> writes:

>> Sounds great!  Does this also apply for the files opened using
>> mm-display-external?
>
> Yes, it does, for the case the mailcap entry specifies neither
> `needsterm' nor `copiousoutput'.  In that case, now it tries to
> delete temporary files one minutes after launching a viewer and
> when Gnus exits[1]. 

I would prefer to not have deletion after one minute, but I'm not
sure what other people think.  For example, if I view an image
using eog, the window goes blank as soon as the file is deleted.

Dan

Re: MIME parts not saved

[Lars Magne Ingebrigtsen]

Dan Christensen <jdc@uwo.ca> writes:

> I would prefer to not have deletion after one minute, but I'm not
> sure what other people think.  For example, if I view an image
> using eog, the window goes blank as soon as the file is deleted.

That's unfortunate, but I think that if you wish to do image treatment
(and stuff), it would make more sense to save the image, and then start
whatever command you want to use on that saved file.  The `v'-iew
related commands are more for viewing.

-- 
(domestic pets only, the antidote for overdose, milk.)
  No Gnus T-Shirt for sale: http://ingebrigtsen.no/no.php
  and http://lars.ingebrigtsen.no/2013/08/twenty-years-of-september.html

Re: MIME parts not saved

[Dan Christensen]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> Dan Christensen <jdc@uwo.ca> writes:
>
>> I would prefer to not have deletion after one minute, but I'm not
>> sure what other people think.  For example, if I view an image
>> using eog, the window goes blank as soon as the file is deleted.
>
> That's unfortunate, but I think that if you wish to do image treatment
> (and stuff), it would make more sense to save the image, and then start
> whatever command you want to use on that saved file.  The `v'-iew
> related commands are more for viewing.

All I'm doing is viewing, using the standard gnome image viewer.  I
pop-up the image of a cat riding a roomba, and by the time I bring my
laptop over to my wife to impress her, all that eog displays is a blank
image.  It would save me a lot of embarrassment(*) if Gnus wouldn't
delete the file until later.  Especially with Katsumi's fancy
delete-at-exit code, there doesn't seem to be much point in deleting
the files using a timer...

There are other programs which are used purely for viewing attachments
which also choke when the file they are viewing disappears, and it's not
unusual to need to spend a lot more than a minute reading a document.

Dan

(*) Or maybe you think the current behaviour is already saving me
some embarrassment?

Re: MIME parts not saved

[Katsumi Yamaoka]

Dan Christensen wrote:
> Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

>> Dan Christensen <jdc@uwo.ca> writes:
>>
>>> I would prefer to not have deletion after one minute, but I'm not
>>> sure what other people think.  For example, if I view an image
>>> using eog, the window goes blank as soon as the file is deleted.
>>
>> That's unfortunate, but I think that if you wish to do image treatment
>> (and stuff), it would make more sense to save the image, and then start
>> whatever command you want to use on that saved file.  The `v'-iew
>> related commands are more for viewing.

> All I'm doing is viewing, using the standard gnome image viewer.  I
> pop-up the image of a cat riding a roomba, and by the time I bring my
> laptop over to my wife to impress her, all that eog displays is a blank
> image.  It would save me a lot of embarrassment(*) if Gnus wouldn't
> delete the file until later.  Especially with Katsumi's fancy
> delete-at-exit code, there doesn't seem to be much point in deleting
> the files using a timer...

> There are other programs which are used purely for viewing attachments
> which also choke when the file they are viewing disappears, and it's not
> unusual to need to spend a lot more than a minute reading a document.

> Dan

> (*) Or maybe you think the current behaviour is already saving me
> some embarrassment?

Please let me make a simple question.  Does it take over one
minute when viewing an image by eog?  Someone said it's fast[1].
If it needs more than one minute, how long should we prolong a
timer value?  I don't think it is down-to-earth if it takes over
one minute, though.

Please see also [2] for the privacy issue.

[1] http://community.linuxmint.com/software/view/eog
[2] http://thread.gmane.org/gmane.emacs.devel/162539

Re: MIME parts not saved

[Katsumi Yamaoka]

Katsumi Yamaoka wrote:
> Please let me make a simple question.  Does it take over one
> minute when viewing an image by eog?  Someone said it's fast[1].
> If it needs more than one minute, how long should we prolong a
> timer value?  I don't think it is down-to-earth if it takes over
> one minute, though.               ^^^^^^^^^^^^^

`down-to-earth' here was misuse.  What I meant was `useful'.
(Dictionaries in Japan sometimes answer in a wrong vector. ;-)

> Please see also [2] for the privacy issue.

> [1] http://community.linuxmint.com/software/view/eog
> [2] http://thread.gmane.org/gmane.emacs.devel/162539

Re: MIME parts not saved

[Adam Sjøgren]

Katsumi Yamaoka <yamaoka@jpl.org> writes:

> Please let me make a simple question.  Does it take over one
> minute when viewing an image by eog?

No, but eog is one of those viewers that monitor the file and update the
view if it changes.

(Can be very nice if you are generating a graph, and you adjust and
regenerate the file, then eog automatically displays the changed graph.)

Unfortunately this also means that eog will stop displaying the image if
the file is deleted.

You could say that eog shouldn't do that (e.g. only update the display
when the file changes, not when deleted), but...

> If it needs more than one minute, how long should we prolong a
> timer value?

Until the viewer quits?

This of course gives us a problem with viewers that detach (eog doesn't
on my machine).

So, maybe only use delete in the timer if the viewer has detached?

> Please see also [2] for the privacy issue.

> [2] http://thread.gmane.org/gmane.emacs.devel/162539

Ugh.


  Best regards,

    Adam

-- 
 "tonight at dusk we go to the house of this former           Adam Sjøgren
  landscape employee and use bricks to remove his        asjo@koldfront.dk
  car windows."

Re: MIME parts not saved

[Dan Christensen]

asjo@koldfront.dk (Adam Sjøgren) writes:

> Katsumi Yamaoka <yamaoka@jpl.org> writes:
>
>> Please let me make a simple question.  Does it take over one
>> minute when viewing an image by eog?
>
> No, but eog is one of those viewers that monitor the file and update the
> view if it changes.

Exactly.

>> Please see also [2] for the privacy issue.
>> [2] http://thread.gmane.org/gmane.emacs.devel/162539

I don't understand the issues there.  Any time I download a pdf file
with my browser, it is saved somewhere on disk (/tmp, by default) and a
viewer is launched.  The browser does no clean-up, and doesn't even hide
the file in a subdirectory of /tmp.  Not to mention the cache of
everything that I view that the browser stores in my home directory.

With Gnus, every attachment that I view is potentially also stored
locally on disk (e.g. if I use a backend that stores files locally), so
why are we worried about another copy stored on disk, as long as it is
readable only by the calling user?

To me, the timer+deletion approach is ugly, unneeded and unreliable.
At the very least, it should be made optional.

Dan

Re: MIME parts not saved

[Katsumi Yamaoka]

Dan Christensen wrote:
> asjo@koldfront.dk (Adam Sjøgren) writes:

>> Katsumi Yamaoka <yamaoka@jpl.org> writes:
>>
>>> Please let me make a simple question.  Does it take over one
>>> minute when viewing an image by eog?
>>
>> No, but eog is one of those viewers that monitor the file and update the
>> view if it changes.

> Exactly.

Adam Sjøgren also wrote:
> (Can be very nice if you are generating a graph, and you adjust and
> regenerate the file, then eog automatically displays the changed
> graph.)

> Unfortunately this also means that eog will stop displaying the
> image if the file is deleted.

For the present Gnus code, it starts the timer when Gnus detects
that the external viewer process exits.  And after one minute,
Gnus tries to delete a data file.  So, the file should not be
deleted while the viewer is running (if not, it's a bug).
Nevertheless does it cause a problem?

However, if eog is launched by way of xdg-open and the like, Gnus
immediately detects that the process of xdg-open, not eog, does
exit, and starts the timer.  In that case, Gnus doesn't know
whether a viewer is still running, and the viewing will fail, if
it is eog, one minute after.  But the solution for this is obvious.
That is to configure the mailcap so as to use a viewer program
directly, rather than to launch a viewer by way of xdg-open.

I'm going to try eog anyway in this weekend.

Re: MIME parts not saved

[Dan Christensen]

Katsumi Yamaoka <yamaoka@jpl.org> writes:

>> Unfortunately this also means that eog will stop displaying the
>> image if the file is deleted.
>
> For the present Gnus code, it starts the timer when Gnus detects
> that the external viewer process exits.

With current git Gnus, I just tried hitting 'e' on a jpg attachment,
which on my system runs the imagemagick display command, and I also
tried running `v eog RET', to manually run eog, and in both cases Gnus
didn't start the 1 minute timer until I quit the viewer.  So this is
working correctly.

Based on the behavior of older versions of Gnus, I had thought that the
timer started right after viewing started.  With the new procedure,
things work fine with eog.

I still anticipate problems, as there are many viewers that hand the
work off to another process and then exit immediately.  For example, if
I want to view an html attachment in google-chrome while I have an
existing google-chrome running, the new process sends a message to the
existing process and then exits.

And programs like xdg-open and gnome-open do the same thing.

So I'd still prefer to leave the temporary files around for much
longer.

Thanks so much for all you have done!  Things are much better than they
were before your improvements.

Dan

Re: MIME parts not saved

[Adam Sjøgren]

Dan Christensen <jdc@uwo.ca> writes:

> And programs like xdg-open and gnome-open do the same thing.

These programs ought to have a '--do-not-detach' option, or something
like that.


  Mvh.

   Adam

-- 
 "Hun si'r hun hedder Lonnie og han si'r han hedder           Adam Sjøgren
  Ben Hun si'r: 'Undskyld, jeg er fra Jylland, kan jeg   asjo@koldfront.dk
  få den igen?"

Re: MIME parts not saved

[Adam Sjøgren]

Katsumi Yamaoka <yamaoka@jpl.org> writes:

> For the present Gnus code, it starts the timer when Gnus detects
> that the external viewer process exits.

Ah, perfect - sorry for making noise without checking the facts.

> However, if eog is launched by way of xdg-open and the like, Gnus
> immediately detects that the process of xdg-open, not eog, does
> exit, and starts the timer.

Yeah, that's the annoying case.

> In that case, Gnus doesn't know whether a viewer is still running, and
> the viewing will fail, if it is eog, one minute after. But the
> solution for this is obvious. That is to configure the mailcap so as
> to use a viewer program directly, rather than to launch a viewer by
> way of xdg-open.

You could do that, but it would be so much nicer if interaction with
those tools "just worked", as they are widespread as defaults (I
think?)...

Except for a longer time-out, I cannot see a better solution - now that
"delete on quit" isn't acceptable, as per the emacs-devel mailing list.

Maybe the time-out could default to 1 minute, but if you configure it to
nil, then the temporary files will be kept until Emacs quits?

Then people who use detaching viewers simply have to set a single
variable, making an informed decision knowing what "problems" this
causes in /tmp/, and everybody is sort of happy?

I thought your solution with "delete on quit" was elegant, for what it's
worth.


  Best regards,

    Adam

-- 
 "It's my chainsaw                                            Adam Sjøgren
  Division is mine"                                      asjo@koldfront.dk