* MIME parts not saved @ 2013-08-02 6:17 John Williams 2013-08-03 11:25 ` Lars Magne Ingebrigtsen 2013-08-05 0:54 ` Katsumi Yamaoka 0 siblings, 2 replies; 25+ messages in thread From: John Williams @ 2013-08-02 6:17 UTC (permalink / raw) To: ding 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 ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: MIME parts not saved 2013-08-02 6:17 MIME parts not saved John Williams @ 2013-08-03 11:25 ` Lars Magne Ingebrigtsen 2013-08-05 3:31 ` John Williams 2013-08-05 0:54 ` Katsumi Yamaoka 1 sibling, 1 reply; 25+ messages in thread From: Lars Magne Ingebrigtsen @ 2013-08-03 11:25 UTC (permalink / raw) To: John Williams; +Cc: ding 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 ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: MIME parts not saved 2013-08-03 11:25 ` Lars Magne Ingebrigtsen @ 2013-08-05 3:31 ` John Williams 0 siblings, 0 replies; 25+ messages in thread From: John Williams @ 2013-08-05 3:31 UTC (permalink / raw) To: ding 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* ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: MIME parts not saved 2013-08-02 6:17 MIME parts not saved John Williams 2013-08-03 11:25 ` Lars Magne Ingebrigtsen @ 2013-08-05 0:54 ` Katsumi Yamaoka 2013-08-05 3:35 ` John Williams 1 sibling, 1 reply; 25+ messages in thread From: Katsumi Yamaoka @ 2013-08-05 0:54 UTC (permalink / raw) To: ding 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? ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: MIME parts not saved 2013-08-05 0:54 ` Katsumi Yamaoka @ 2013-08-05 3:35 ` John Williams 2013-08-05 11:25 ` Katsumi Yamaoka 0 siblings, 1 reply; 25+ messages in thread From: John Williams @ 2013-08-05 3:35 UTC (permalink / raw) To: ding 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 ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: MIME parts not saved 2013-08-05 3:35 ` John Williams @ 2013-08-05 11:25 ` Katsumi Yamaoka 2013-08-05 15:16 ` Katsumi Yamaoka 0 siblings, 1 reply; 25+ messages in thread From: Katsumi Yamaoka @ 2013-08-05 11:25 UTC (permalink / raw) To: ding [-- 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*" ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: MIME parts not saved 2013-08-05 11:25 ` Katsumi Yamaoka @ 2013-08-05 15:16 ` Katsumi Yamaoka 2013-08-06 13:52 ` Katsumi Yamaoka 0 siblings, 1 reply; 25+ messages in thread From: Katsumi Yamaoka @ 2013-08-05 15:16 UTC (permalink / raw) To: ding [-- 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) ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: MIME parts not saved 2013-08-05 15:16 ` Katsumi Yamaoka @ 2013-08-06 13:52 ` Katsumi Yamaoka 2013-08-07 14:22 ` Dan Christensen 0 siblings, 1 reply; 25+ messages in thread From: Katsumi Yamaoka @ 2013-08-06 13:52 UTC (permalink / raw) To: ding 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. ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: MIME parts not saved 2013-08-06 13:52 ` Katsumi Yamaoka @ 2013-08-07 14:22 ` Dan Christensen 2013-08-08 0:43 ` Katsumi Yamaoka 0 siblings, 1 reply; 25+ messages in thread From: Dan Christensen @ 2013-08-07 14:22 UTC (permalink / raw) To: ding 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 ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: MIME parts not saved 2013-08-07 14:22 ` Dan Christensen @ 2013-08-08 0:43 ` Katsumi Yamaoka 2013-08-09 8:06 ` Katsumi Yamaoka 0 siblings, 1 reply; 25+ messages in thread From: Katsumi Yamaoka @ 2013-08-08 0:43 UTC (permalink / raw) To: ding 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. ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: MIME parts not saved 2013-08-08 0:43 ` Katsumi Yamaoka @ 2013-08-09 8:06 ` Katsumi Yamaoka 2013-08-09 23:20 ` Dan Christensen 0 siblings, 1 reply; 25+ messages in thread From: Katsumi Yamaoka @ 2013-08-09 8:06 UTC (permalink / raw) To: ding 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'. ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: MIME parts not saved 2013-08-09 8:06 ` Katsumi Yamaoka @ 2013-08-09 23:20 ` Dan Christensen 2013-08-12 2:38 ` Katsumi Yamaoka 0 siblings, 1 reply; 25+ messages in thread From: Dan Christensen @ 2013-08-09 23:20 UTC (permalink / raw) To: ding 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 ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: MIME parts not saved 2013-08-09 23:20 ` Dan Christensen @ 2013-08-12 2:38 ` Katsumi Yamaoka 2013-08-12 5:59 ` Katsumi Yamaoka 2013-08-12 14:09 ` Dan Christensen 0 siblings, 2 replies; 25+ messages in thread From: Katsumi Yamaoka @ 2013-08-12 2:38 UTC (permalink / raw) To: ding 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. ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: MIME parts not saved 2013-08-12 2:38 ` Katsumi Yamaoka @ 2013-08-12 5:59 ` Katsumi Yamaoka 2013-08-12 14:09 ` Dan Christensen 1 sibling, 0 replies; 25+ messages in thread From: Katsumi Yamaoka @ 2013-08-12 5:59 UTC (permalink / raw) To: ding 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. ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: MIME parts not saved 2013-08-12 2:38 ` Katsumi Yamaoka 2013-08-12 5:59 ` Katsumi Yamaoka @ 2013-08-12 14:09 ` Dan Christensen 2013-08-12 17:18 ` Lars Magne Ingebrigtsen 1 sibling, 1 reply; 25+ messages in thread From: Dan Christensen @ 2013-08-12 14:09 UTC (permalink / raw) To: ding 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 ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: MIME parts not saved 2013-08-12 14:09 ` Dan Christensen @ 2013-08-12 17:18 ` Lars Magne Ingebrigtsen 2013-08-13 2:29 ` Dan Christensen 0 siblings, 1 reply; 25+ messages in thread From: Lars Magne Ingebrigtsen @ 2013-08-12 17:18 UTC (permalink / raw) To: ding 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 ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: MIME parts not saved 2013-08-12 17:18 ` Lars Magne Ingebrigtsen @ 2013-08-13 2:29 ` Dan Christensen 2013-08-13 4:02 ` Katsumi Yamaoka 0 siblings, 1 reply; 25+ messages in thread From: Dan Christensen @ 2013-08-13 2:29 UTC (permalink / raw) To: ding 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? ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: MIME parts not saved 2013-08-13 2:29 ` Dan Christensen @ 2013-08-13 4:02 ` Katsumi Yamaoka 2013-08-13 5:22 ` Katsumi Yamaoka 2013-08-13 10:43 ` Adam Sjøgren 0 siblings, 2 replies; 25+ messages in thread From: Katsumi Yamaoka @ 2013-08-13 4:02 UTC (permalink / raw) To: ding 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 ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: MIME parts not saved 2013-08-13 4:02 ` Katsumi Yamaoka @ 2013-08-13 5:22 ` Katsumi Yamaoka 2013-08-13 10:43 ` Adam Sjøgren 1 sibling, 0 replies; 25+ messages in thread From: Katsumi Yamaoka @ 2013-08-13 5:22 UTC (permalink / raw) To: ding 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 ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: MIME parts not saved 2013-08-13 4:02 ` Katsumi Yamaoka 2013-08-13 5:22 ` Katsumi Yamaoka @ 2013-08-13 10:43 ` Adam Sjøgren 2013-08-13 20:47 ` Dan Christensen 1 sibling, 1 reply; 25+ messages in thread From: Adam Sjøgren @ 2013-08-13 10:43 UTC (permalink / raw) To: ding 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." ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: MIME parts not saved 2013-08-13 10:43 ` Adam Sjøgren @ 2013-08-13 20:47 ` Dan Christensen 2013-08-13 23:50 ` Katsumi Yamaoka 0 siblings, 1 reply; 25+ messages in thread From: Dan Christensen @ 2013-08-13 20:47 UTC (permalink / raw) To: ding 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 ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: MIME parts not saved 2013-08-13 20:47 ` Dan Christensen @ 2013-08-13 23:50 ` Katsumi Yamaoka 2013-08-14 1:41 ` Dan Christensen 2013-08-14 8:58 ` Adam Sjøgren 0 siblings, 2 replies; 25+ messages in thread From: Katsumi Yamaoka @ 2013-08-13 23:50 UTC (permalink / raw) To: ding 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. ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: MIME parts not saved 2013-08-13 23:50 ` Katsumi Yamaoka @ 2013-08-14 1:41 ` Dan Christensen 2013-08-14 8:52 ` Adam Sjøgren 2013-08-14 8:58 ` Adam Sjøgren 1 sibling, 1 reply; 25+ messages in thread From: Dan Christensen @ 2013-08-14 1:41 UTC (permalink / raw) To: ding 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 ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: MIME parts not saved 2013-08-14 1:41 ` Dan Christensen @ 2013-08-14 8:52 ` Adam Sjøgren 0 siblings, 0 replies; 25+ messages in thread From: Adam Sjøgren @ 2013-08-14 8:52 UTC (permalink / raw) To: ding 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?" ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: MIME parts not saved 2013-08-13 23:50 ` Katsumi Yamaoka 2013-08-14 1:41 ` Dan Christensen @ 2013-08-14 8:58 ` Adam Sjøgren 1 sibling, 0 replies; 25+ messages in thread From: Adam Sjøgren @ 2013-08-14 8:58 UTC (permalink / raw) To: ding 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 ^ permalink raw reply [flat|nested] 25+ messages in thread
end of thread, other threads:[~2013-08-14 8:58 UTC | newest] Thread overview: 25+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2013-08-02 6:17 MIME parts not saved John Williams 2013-08-03 11:25 ` Lars Magne Ingebrigtsen 2013-08-05 3:31 ` John Williams 2013-08-05 0:54 ` Katsumi Yamaoka 2013-08-05 3:35 ` John Williams 2013-08-05 11:25 ` Katsumi Yamaoka 2013-08-05 15:16 ` Katsumi Yamaoka 2013-08-06 13:52 ` Katsumi Yamaoka 2013-08-07 14:22 ` Dan Christensen 2013-08-08 0:43 ` Katsumi Yamaoka 2013-08-09 8:06 ` Katsumi Yamaoka 2013-08-09 23:20 ` Dan Christensen 2013-08-12 2:38 ` Katsumi Yamaoka 2013-08-12 5:59 ` Katsumi Yamaoka 2013-08-12 14:09 ` Dan Christensen 2013-08-12 17:18 ` Lars Magne Ingebrigtsen 2013-08-13 2:29 ` Dan Christensen 2013-08-13 4:02 ` Katsumi Yamaoka 2013-08-13 5:22 ` Katsumi Yamaoka 2013-08-13 10:43 ` Adam Sjøgren 2013-08-13 20:47 ` Dan Christensen 2013-08-13 23:50 ` Katsumi Yamaoka 2013-08-14 1:41 ` Dan Christensen 2013-08-14 8:52 ` Adam Sjøgren 2013-08-14 8:58 ` Adam Sjøgren
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).