bug#63842: 30.0.50; Slow 'gnus-summary-refer-thread'

[Manuel Giraud via "Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>]

Manuel Giraud <manuel@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