[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: locks xemacs on download
- From: Katsumi Yamaoka <yamaoka@xxxxxxx>
- Date: Fri, 21 Jan 2005 09:16:36 +0900
- X-ml-name: emacs-w3m
- X-mail-count: 07431
- References: <m27jm8ynlw.fsf@maya.dyndns.org>
>>>>> In [emacs-w3m : No.07430] Gary Lawrence Murphy wrote:
> Dear Bug Team!
> Ok, I've confirmed this three times in a row so it's reliable
> on my setup: Mandrake 10.1, P3/700MHz machine with only 512MB
> (ie, just a little cramped) running Gnome desktop and XEmacs
> with the current CVS image emacs-w3m
Thank you for the report but we may be able to do nothing. I
also frequently experience the situation that the recent XEmacs
21.4 locks. It occurs not only with emacs-w3m but also with all
other applications, for example, Gnus. Perhaps, the place to
which you should go might be the xemacs-beta list. It is
because (X)Emacs must not lock or die no matter what ELisp
programs do. It will be helpful if I could identify the
definite condition which causes locks. However I have never
found it so far.
> if I go to http://www.bricolage.cc and put the point on the
> download-current link, then press 'd' I am prompted for a location,
> which I edit and then hit return. the message says this is async;
> if I load any other w3m pages (or maybe just wait?) the XEmacs
> GUI will completely lock up, no repaints, and no file appears in
> the specified directory. the process table says XEmacs is still
> alive and at the top of the list, but I waited several minutes
> and it still did not repaint any moved or un-covered windows.
> XEmacs does respond to a normal kill signal, so it likely is still
> alive, but the XEmacs display is very locked. The rest of the
> desktop is unaffected.
I doubt that XEmacs spends a very long time to do a certain
processing in such a case but I don't know what it is. Sigh.
P.S. I used to be a supporter of ardent XEmacs, but...