Description of problem: The above message shows up each time I try to look at an attachment in an email message that is in PDF or .doc. HTML works fine. Version-Release number of selected component (if applicable): xemacs-packages-extra-20070427-1.fc8.noarch How reproducible: Always Steps to Reproduce: 1. Open a message with .doc attachment in MH-E buffer 2. Mouse-2 click on attachment 3 [details]. Actual results: Expected results: Additional info:
Unfortunately I know next to nothing about mh-e and don't even have it set up to test, so all I can do at the moment is to ask if you could test if this happens with the latest experimental mh-e package at http://ftp.xemacs.org/beta/experimental/packages/ too. Instructions how to test upstream experimental packages are eg. in bug 432101 comment 1. Grepping for timer-list in the whole current XEmacs packages CVS tree reveals only one use of it in vm/vm-folder.el which also ensures that it is defined as a variable so I'm somewhat at loss about where this error might come from. timer-list is defined in timer.el in the fsf-compat package so another thing you could try is to load the timer library before invoking mh-e and see if it makes any difference.
mh-e-1.31-pkg.tar.gz shows the same. 'M-x load-library timer' before MH-E now gives just: Displaying /usr/bin/xdg-open /tmp/vonbrand/emm.ewFpez/ATT00070.doc...done and displays nothing whatsoever. When it works the "done" shows up only when you exit the viewed file. The attached file has the name ATT00070.doc, but the temporary directory doesn't exist at all. Under /tmp there is no file with the name ATT00070.doc. It seems that there are two bugs here: - Not using the timer properly (timeout for the command to start/finish?) - Not saving the attachment in the right directory
Ok, I found where that stuff comes from, it's in gnus' mm-decode.el. Getting rid of the initial problem where timer-list is not bound seems pretty trivial (no need to load the timer library separately any more), could you test installing this package like you tested the experimental mh-e package: http://scop.fedorapeople.org/tmp/gnus-1.92-pkg.tar.gz But why the attachment doesn't show up for you is still a mystery. I don't think there's anything necessarily wrong with the directory - if I understand correctly the timer is used to delete the temporary dir after the viewer has launched. Does running xdg-open on a *.doc file from the console outside of XEmacs open it with some viewer? For me in F8 KDE, OpenOffice.org writer is launched.
OK, installed that package (and I still have the experimental mh-e), now there is no more error messages. But the attachments don't show. Again, the directory mentioned isn't there. Atachments in HTML open a tab in firefox OK. Also, /now/ there is a /tmp/vonbrand/emm.14A4lW/ATT00070.doc (note that the filename is the one from an earlier attachment I couldn't see), but the directory name is different. I didn't mess around with that message in between. Yes, running xdg-open with the offending files (after unpacking them) does work OK. The manpage says it opens the files with the "preferred application", and this works (I.e., that one is set (somehow) to oowriter for .doc here).
Don't pay too much attention to the /tmp/... file/dir names - I think mm-decode.el creates a temporary directory every time it decodes an attachment for viewing (and is supposed to remove it after the viewer has launched but apparently fails to do so sometimes). I've forwarded the gnus change I made to upstream, but unfortunately the rest of this issue remains a mystery to me.
The folks on the MH-E users list <mh-e-users.net> might be able to help with any remaining issues.
Changing version to '9' as part of upcoming Fedora 9 GA. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
I also am unable to view PDF or Word attachments using emacs. I am using GNUS running on Fedora 9. This used to work for me. It appears to me that the problem is that xdg-open exits immediately and does the job in a child process. When viewing an attachment in GNUS, emacs appears to create a temporary file, start the helper program, wait for the helper program to exit, and then remove the temporary file. What appears to be happening here is that emacs creates the temporary file, starts xdg-open, xdg-open exits immediately, emacs removes the temporary file, xdg-open doesn't know what to do. If I save the file to disk and then run xdg-open, I am able to view it. So I'm not sure about it but this appears to be a mismatch between what emacs expects of a helper program and how the helper program actually works. It's rather annoying. It used to work correctly in earlier versions of Fedora, ones which did not use xdg-open.
That could very well be it. Except that I don't think it's xdg-open's fault. Looking at xdg-open code, it sticks around until the tool it invokes exits. Do you use GNOME? In my tests, this: echo foo > /tmp/test.txt ; gnome-open /tmp/test.txt ; rm /tmp/test.txt ...consistently results in an empty file being opened in an editor, whereas: echo foo > /tmp/test.txt ; kfmclient exec /tmp/test.txt ; rm /tmp/test.txt ...results in a text file containing "foo" opened in an editor. In my opinion, this would be a gnome-open bug; I've filed bug 472402 against libgnome, let's see what the maintainers have to say about it. And just to clarify, Ian, you mention "emacs" but this bug is against xemacs-packages-extra (a bunch of extra packages for XEmacs) - do you use GNU Emacs or XEmacs?
[Changed to rawhide, still seeing it here on x86_64 now] Yes, I'm using Gnome and xemacs. I just tried the "gnome-open" version of #9 (no kfmclient here), and I get an empty file too.
I use GNOME. I am using emacs, not xemacs.
This bug appears to have been reported against 'rawhide' during the Fedora 10 development cycle. Changing version to '10'. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component.
> echo foo > /tmp/test.txt ; kfmclient exec /tmp/test.txt ; rm /tmp/test.txt > ...results in a text file containing "foo" opened in an editor. I'm not sure this can be depended on. kfmclient is also asynchronous in the sense that it returns before the application is closed. So if the application is a bit slower to open the file, it'll also lose the race.
Thanks, that's good information. So it appears that xdg-open, as currently constructed, is simply not usable for temporary file viewing/editing. Would you mind chiming in on the thread with subject "(A)synchronous file operations & xdg-open" on fedora-devel-list? This information would be useful there.
Is the attachment viewing problem solved if you customize browse-url-xdg-open-program to the name of your preferred web browser? You may have to (require 'browse-url) before you can customize it.
Or, possibly better yet, try customizing browse-url-xdg-open-program to nil. Let me know if either solves the problem for you.
This message is a reminder that Fedora 10 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 10. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '10'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 10's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 10 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Fedora 10 changed to end-of-life (EOL) status on 2009-12-17. Fedora 10 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed.