Andrew Cohen <aco...@ust.hk> writes:
>>>>>> "EA" == Eric Abrahamsen <e...@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.
Thanks for the swift and thorough response!
> Maybe its backend specific? I am using imap... I suspect it is still
> some kind of notmuch problem.
I really, really hope not, as the whole point of all this was complete
code isolation. I don't see how it could be, as new-nnselect-artlist was
populated correctly, and after that notmuch doesn't seem to be involved.
> 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.
In my edebugging test, "new-nnselect-artlist" held the correct
(newly-found) article vectors. Then when the code got here:
(append (sort old-arts #'<)
(number-sequence first last))
old-arts held all the newly-found article numbers. So the mapc seemed to
add all articles in "new-nnselect-artlist".
Then "first" was 2 and "last" was 1, so `number-sequence' returned nil
-- that's expected, yes?
Then I stepped forward to the `gnus-fetch-headers' call, and got args
out of range, the sequence being a vector holding the single vector of
the _original_ message that was in the nnselect group, and the index
being 14, the highest of the newly-found article numbers.
Setting up testing takes a little bit, I'm going to do some automation
for gnus-mock, and then jump back into this.
Thanks again,
Eric
