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

Previous Next

Full log

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

From: Manuel Giraud <manuel <at> ledu-giraud.fr>
To: Andrew Cohen <cohen <at> bu.edu>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 63842 <at> debbugs.gnu.org, cohen <at> andy.bu.edu
Subject: Re: bug#63842: 30.0.50; Slow 'gnus-summary-refer-thread'
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.
-- 
Manuel Giraud

Previous Next

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