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

From: Eli Zaretskii <[email-masked]>
Date: Sat, 01 Jul 2023 11:25:02 +0300

> From: Manuel Giraud <[email-masked]>
> Cc: Eli Zaretskii <[email-masked]>,  [email-masked],  [email-masked]
> Date: Fri, 23 Jun 2023 12:00:45 +0200
> 
> Manuel Giraud <[email-masked]> 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?