GNU bug report logs - #63842
30.0.50; Slow 'gnus-summary-refer-thread'

Previous Next

Full log

Message #47 received at 63842 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Manuel Giraud <manuel <at> ledu-giraud.fr>
Cc: cohen <at> bu.edu, 63842 <at> debbugs.gnu.org, cohen <at> andy.bu.edu
Subject: Re: bug#63842: 30.0.50; Slow 'gnus-summary-refer-thread'
Date: Sat, 01 Jul 2023 11:25:02 +0300

> From: Manuel Giraud <manuel <at> ledu-giraud.fr>
> Cc: Eli Zaretskii <eliz <at> gnu.org>,  63842 <at> debbugs.gnu.org,  cohen <at> andy.bu.edu
> Date: Fri, 23 Jun 2023 12:00:45 +0200
> 
> Manuel Giraud <manuel <at> ledu-giraud.fr> writes:
> 
> [...]
> 
> >> To get everything right, any articles in the thread that need to be
> >> added to the summary buffer have to be added to the dependencies
> >> hash. In the case of searching we know exactly which articles need to
> >> be added so we have no need for 'gnus-read-all-available-headers to be
> >> non-nil: the "found" articles are each added to the hash. The only
> >> case where 'gnus-read-all-available-headers needs to be non-nil is
> >> when we don't know exactly which articles are part of the thread in
> >> which case we have to parse a larger set. This is what happens in the
> >> 3rd case in the conditional (the "t" clause) in
> >> 'gnus-summary-refer-thread. That is, this variable is only relevant in
> >> those cases where we don't have a configured search engine and just
> >> retrieve a lot of headers and hope for the best. So the setting of
> >> 'gnus-read-all-available-headers is just in the wrong place.
> >
> > Thanks.  I don't know for other backends/search engines but a binding of
> > 'gnus-read-all-available-headers' to t elsewhere will sure fix my
> > issue.
> 
> Hi Andrew,
> 
> I have seen your patch and it works as expected.
> 'gnus-summary-refer-thread' is as fast as before for me.  Thanks.

Thanks.  can the fix be installed and the bug closed then, please?

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.