Re: gnus-search-engine set to gnus-search-notmuch and refer threads

[Andrew Cohen]

>>>>> "EA" == Eric Abrahamsen <eric@ericabrahamsen.net> writes:


[...]


    EA> Next, I think it's a reasonable design decision to say that
    EA> referring a thread from within an nnselect group should search
    EA> that group's constituent groups, not the group itself. What I'm
    EA> seeing is that nnselect actually does that (if we're using
    EA> search for thread-referral, it nixes out the group argument and
    EA> searches the whole original server(s)), but then an error is
    EA> raised later on, when we try to fetch the headers (line 656). I
    EA> can see that all the thread article numbers are returned
    EA> correctly, but then when we get to `gnus-fetch-headers' I get an
    EA> args-out-of-range error, it looks like because we're looking for
    EA> the index of an article number in the original (smaller) list of
    EA> newsgroup headers. This was referring a thread from a summary
    EA> buffer that contained only a single message.

    EA> Andy, does that sound familiar?

Err, no. I use this constantly in nnselect groups and have no
errors. And I just tried it with an nnselect summary buffer with a
single message with no trouble.

Maybe its backend specific? I am using imap... I suspect it is still
some kind of notmuch problem.

I admit the code for this is a bit hairy, but it tries to do the
following:

Identify the potential groups that might hold related articles (this is
a bit more than just searching all the groups; If
=gnus-refer-thread-use-search= is true, search ALL groups on the
corresponding servers in the current nnselect group, but this isn't
relevant here).

If any hits are found they are MERGED into the nnselect group (by
extending the selection). Then the headers are retrieved with
=gnus-fetch-headers=.

Gory details to help debugging:

The search results are held in new-nnselect-artlist, so you can inspect
this to see if the search result is correct---it should be the usual vector of
vectors e.g. [["nnimap+server:group" 47 100] ["nnimap+server:group" 49
100]]. 

The mapc merges these into the current selection (its a merge rather
than append because some of the searched-for articles are already in the
selection; the virtual group numbers of these articles are collected in
=old-arts=).  As a side effect it counts the number of genuinely new
articles, numbered =first= to =last=.

Then we fetch the headers of all the articles in the thread (both the
old and the new). That is the =gnus-fetch-headers= in the next code
block.  You can check this by comparing with the
=gnus-newsgroup-selection=; this is the full vector of articles (all the
original articles in the nnselect plus all the new ones). The virtual
group article number is just the location in the vector. So you can
compare old-arts, first, and last to see that it is all correct.



-- 
Andrew Cohen