Bug 188973

(In reply to comment #0)
> xemacs spews errors and warnings about its configuration, moving it out of the
> way doesn't help much.

By "its configuration", I assume you mean stuff in your ~/.xemacs?
Please post the errors and warnings you get.

> moving it out of the way doesn't help much

How does doing so affect things?  What about xemacs -vanilla and/or xemacs -q?

> Steps to Reproduce:
> 1. Start xemacs
> 2. M-x mh-rmail

Before doing the above, I installed nmh, ran install-mh, created the
~/Mail/inbox directory.  The did the above, inbox is obviously empty but no
warnings or errors are printed anywhere, nor any hangs witnessed, and menubar
works as usual.

Now I had time to look a bit further into the problem. It turned out that my
~/.xemacs/init.el contained:

   ;;; UTF-8

   (require 'un-define)
   (set-coding-priority-list '(utf-8))
   (set-coding-category-system 'utf-8 'utf-8)

and commenting that out fixed the complaints when starting up.

Sorry for the noise.

Tried it again now. Now I think it is:
1. Start xemacs
2. Get new mail (M-x mh-rmail)
3. Delete some mail

Hangs in "Fontifying +inbox... (regexps)"

Moving the mouse over the different buttons gives messages in the message
buffer, but there is no reaction (i.e., I can't go to the *Warnings* buffer to
copy it here). I just see:

  Warning:  Error in 'pre-idle hook' (resetting to nil): Attempt to throw
outside of function:To catch 'call-process-done' with value '0'

I had to enlarge the window to get to see this, trying to kill it via the 'X'
button goes nowhere. The slide bar stays put, even though the window grows. You
can move the slider, but it doesn't move through the buffer.

Created attachment 127791 [details]
.xemacs/init.el

My configuration (custom.el to follow)

Created attachment 127792 [details]
~/.xemacs/custom.el

Second piece of my configuration

I thought this had been fixed with xemacs-21.5.26-3.fc6, but it still hangs just
the same.

A bit of googling around revealed this (see also the followup):
http://list-archive.xemacs.org/xemacs-beta/200509/msg00225.html

I'm inclined to think that this is an upstream bug and not a packaging one, so
asking on xemacs-beta could be the best way to get someone familiar
with this stuff to look into it.  Would you mind doing that?

I just reported the bug (against xemacs-21.5.27-1.fc6) via the bug report
mechanism in it.

Still the same, now with xemacs-21.5.27-3.fc6. The one in FC5 works fine, so I'm
using that one.

The XEmacs mailing list archives are down ATM, so hopefully I'm not suggesting
the same thing for the second time, but could you try adding this to
~/.xemacs/init.el and see if it affects anything:

  (setq progress-feedback-use-echo-area t)

(From http://sf.net/tracker/?func=detail&atid=213357&aid=1323760&group_id=13357 )

Yup, that seems to cure it. And boy, is the new one faster!

In any case, this is then an xemacs bug, being worked on upstream. I don't know
enough about RH BZ etiquette to say if it should be closed now, etc.

Thanks for the confirmation.

I'll leave this open to remind that we'd probably be better off disabling the
graphical progress bar in the default out of the box config until it's fixed
upstream.

Done in 21.5.27-4