Bug 435107 - "Symbol's value as variable is void: timer-list"
"Symbol's value as variable is void: timer-list"
Product: Fedora
Classification: Fedora
Component: xemacs-packages-extra (Show other bugs)
All Linux
low Severity low
: ---
: ---
Assigned To: Jerry James
Fedora Extras Quality Assurance
: Triaged
Depends On:
  Show dependency treegraph
Reported: 2008-02-27 07:43 EST by Horst H. von Brand
Modified: 2009-12-18 01:04 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2009-12-18 01:04:30 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Horst H. von Brand 2008-02-27 07:43:12 EST
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):

How reproducible:

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:
Comment 1 Ville Skyttä 2008-03-10 18:49:15 EDT
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.
Comment 2 Horst H. von Brand 2008-03-11 13:46:51 EDT
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
Comment 3 Ville Skyttä 2008-03-11 15:29:31 EDT
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:

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

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.
Comment 4 Horst H. von Brand 2008-03-11 16:30:50 EDT
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).
Comment 5 Ville Skyttä 2008-03-12 15:35:19 EDT
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.
Comment 6 Mike Kupfer 2008-03-15 17:44:09 EDT
The folks on the MH-E users list <mh-e-users@lists.sourceforge.net> might be
able to help with any remaining issues.
Comment 7 Bug Zapper 2008-05-14 01:39:49 EDT
Changing version to '9' as part of upcoming Fedora 9 GA.
More information and reason for this action is here:
Comment 8 Ian Lance Taylor 2008-11-19 21:25:19 EST
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.
Comment 9 Ville Skyttä 2008-11-20 12:28:37 EST
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?
Comment 10 Horst H. von Brand 2008-11-20 17:19:06 EST
[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.
Comment 11 Ian Lance Taylor 2008-11-22 20:54:48 EST
I use GNOME.

I am using emacs, not xemacs.
Comment 12 Bug Zapper 2008-11-25 21:08:06 EST
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:
Comment 13 Fedora Admin XMLRPC Client 2009-06-15 14:02:51 EDT
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.
Comment 14 Kevin Kofler 2009-06-26 17:12:14 EDT
> 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.
Comment 15 Jerry James 2009-06-26 17:22:02 EDT
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.
Comment 16 Jerry James 2009-07-02 14:54:47 EDT
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.
Comment 17 Jerry James 2009-07-02 15:09:48 EDT
Or, possibly better yet, try customizing browse-url-xdg-open-program to nil.  Let me know if either solves the problem for you.
Comment 18 Bug Zapper 2009-11-18 07:26:18 EST
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: 
Comment 19 Bug Zapper 2009-12-18 01:04:30 EST
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.

Note You need to log in before you can comment on or make changes to this bug.