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

[Andrew Cohen <cohen@bu.edu>]

>>>>> "MG" == Manuel Giraud <manuel@ledu-giraud.fr> writes:

    MG> Andrew Cohen <cohen@bu.edu> writes:
    >> OK, I think I understand the problem.

[...]

    MG> From my tiny testing set, it does not seems to me that parsing
    MG> all the headers is the way to go: the call to
    MG> 'gnus-search-run-query' in gnus-search.el line 2206 directly
    MG> returns direcly the correct set of messages and the call to
    MG> 'gnus-get-newsgroup-headers-xover' later looks like some "deep"
    MG> search (eg. on subject content).

OK, I understand it now.  This isn't really about searching, or subject
content (the fact that Manuel sees some articles not in the thread but
with similar subject remains a bit of a mystery). 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 to Manuel for figuring out the error. I'll push the fix shortly.

Best,
Andy

-- 
Andrew Cohen