From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/36498 Path: main.gmane.org!not-for-mail From: Paul Stodghill Newsgroups: gmane.emacs.gnus.general Subject: Re: fill bug still there [Re: XEmacs 21.[45] + Oort Gnus 0.03 + Filladapt 2.12: Inf loop] Date: 29 May 2001 13:26:23 -0400 Sender: stodghil@milhouse.cs.cornell.edu Message-ID: References: <3B092ED2.F390356F@inrialpes.fr> <3B092ED2.F390356F@inrialpes.fr> <4.3.2.7.2.20010521090646.00d66480@san-francisco.beasys.com> NNTP-Posting-Host: coloc-standby.netfonds.no Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit X-Trace: main.gmane.org 1035172072 8908 80.91.224.250 (21 Oct 2002 03:47:52 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Mon, 21 Oct 2002 03:47:52 +0000 (UTC) Cc: ding@gnus.org Return-Path: Original-Received: (qmail 20450 invoked by alias); 29 May 2001 17:26:24 -0000 Original-Received: (qmail 20445 invoked from network); 29 May 2001 17:26:24 -0000 Original-Received: from postoffice.mail.cornell.edu (132.236.56.7) by gnus.org with SMTP; 29 May 2001 17:26:24 -0000 Original-Received: from milhouse.cs.cornell.edu.cs.cornell.edu (dhcp99-208.cs.cornell.edu [128.84.99.208]) by postoffice.mail.cornell.edu (8.9.3/8.9.3) with ESMTP id NAA25676; Tue, 29 May 2001 13:26:23 -0400 (EDT) Original-To: Kai.Grossjohann@CS.Uni-Dortmund.DE (Kai Großjohann) In-Reply-To: (Kai.Grossjohann@CS.Uni-Dortmund.DE's message of "29 May 2001 19:22:20 +0200") User-Agent: Gnus/5.090003 (Oort Gnus v0.03) XEmacs/21.5 (anise) Original-Lines: 12 Xref: main.gmane.org gmane.emacs.gnus.general:36498 X-Report-Spam: http://spam.gmane.org/gmane.emacs.gnus.general:36498 >>>>> "Kai" == Kai Großjohann writes: Kai> It seems that the lockup is caused by filladapt. Does it go away Kai> when you disable filladapt? Or is filladapt always enabled in Kai> XEmacs? It is filladapt related. Turning filladapt off in message mode fixes the problem. HOWEVER, I have not that filladapt infloops in any other mode AND this problem did not exist in v5.8.8.