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

[Eli Zaretskii <eliz@gnu.org>]

> From: Manuel Giraud <manuel@ledu-giraud.fr>
> Cc: Eli Zaretskii <eliz@gnu.org>,  63842@debbugs.gnu.org,  cohen@andy.bu.edu
> Date: Fri, 23 Jun 2023 12:00:45 +0200
> 
> 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.

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