Description of problem: In an MH-E folder buffer, pressing "T t" (to thread it) just gives 'End of file or stream: "internal input stream"', the folder isn't threaded Version-Release number of selected component (if applicable): xemacs-packages-extra-el-20060510-4.fc6 How reproducible: Always Steps to Reproduce: 1. M-x mh-rmail 2. Tt 3. Actual results: End of file or stream: "internal input stream" Expected results: Threaded folder Additional info xemacs-21.5.27-8.fc7, it used to work with the version before this one.
(In reply to comment #0) > xemacs-21.5.27-8.fc7, it used to work with the version before this one. Hm, previous version of xemacs or xemacs-packages-extra? Which are the exact versions of xemacs and xemacs-packages-extra it worked with?
xemacs, xemacs-packages-extra hasn't changed in ages (it is still .fc6). xemacs-packages-{base,extra} are from Sep 10, 2006, installed the next day. I dunno which version of xemacs was before, the rotation of yum.log erased the record of that one's installation.
The only changes between xemacs 21.5.27-7.fc7 and 8.fc7 were these: http://cvs.fedora.redhat.com/viewcvs/devel/xemacs/xemacs-21.5.27-canna-222559.patch?root=extras&rev=1.1&view=auto http://cvs.fedora.redhat.com/viewcvs/devel/xemacs/xemacs-sitestart.el?root=extras&r1=1.6&r2=1.7 Both look innocent enough to me, but perhaps you could test if reverting the site-start.el change has any effect. What's your $LANG environment variable set to?
LANG=en_US.UTF-8 In any case, this went away (by mistake I tried reading email in xemacs, and it worked this time, after reliably *not* working starting last week). Sorry, I can't point at any of the many updates to rawhide which fixed this. I guess you can close it now... sorry for the time wasted. Thanks!
Sorry, false alarm. When threading a huge folder (a few thousand messages, message numbers up in the 80 thousands) it hung again. The workaround was to thread the folder in plain emacs, delete a few hundred messages (junk easily sorted by Subject:) and get at it again in xemacs.
Futzing around with GNU emacs, it seems that when deleting a large number of messages (or large messages) it runs out of "undo" space (that is the message GNU emacs gives, instead of just hanging). Why does it save the deleted messages in undo? MH saves them as ",<msg>" in the folder, so they aren't lost. I suspect this is what makes many MH-E operations slow.
After not using xemacs for quite some time for email, I tried again. I now seems to work (xemacs-21.5.28-5.fc8, xemacs-packages-extra-20070427-1.fc8, nmh-1.2-20070115cvs.4.fc8).
Thanks for the feedback, assuming fixed.