Announcements and discussions for Gnus, the GNU Emacs Usenet newsreader
 help / color / mirror / Atom feed
* Re: gnus-search-engine set to gnus-search-notmuch and refer threads
@ 2022-02-18  1:20 Eric Abrahamsen
  0 siblings, 0 replies; 25+ messages in thread
From: Eric Abrahamsen @ 2022-02-18  1:20 UTC (permalink / raw)
  To: info-gnus-english

Andrew Cohen <acohen@ust.hk> writes:

>>>>>> "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.

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



^ permalink raw reply	[flat|nested] 25+ messages in thread

end of thread, other threads:[~2022-02-18  7:36 UTC | newest]

Thread overview: 25+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
     [not found] <87lf1k11ed.fsf@onenetbeyond.org>
2021-11-19 19:05 ` gnus-search-engine set to gnus-search-notmuch and refer threads jao
2021-12-14 21:41   ` dal-blazej
2021-12-15 17:41     ` Eric Abrahamsen
2021-12-18 23:22       ` dal-blazej
2021-12-21  5:56     ` Andrew Cohen
2021-12-22 20:56       ` Jose A. Ortega Ruiz
2021-12-22 21:16         ` Eric Abrahamsen
2021-12-22 21:19           ` Eric Abrahamsen
2021-12-22 23:01             ` Jose A. Ortega Ruiz
2021-12-23  0:30               ` Eric Abrahamsen
2021-12-23  3:34                 ` Jose A. Ortega Ruiz
2021-12-23 20:55               ` Eric Abrahamsen
2021-12-24  3:08                 ` Jose A. Ortega Ruiz
2021-12-27 21:54                   ` Jose A. Ortega Ruiz
2021-12-30 23:51                     ` Eric Abrahamsen
2021-12-31  0:07                       ` Andrew Cohen
2021-12-31  0:20                         ` Eric Abrahamsen
2021-12-31  0:37                           ` Andrew Cohen
2021-12-31  1:13                             ` Eric Abrahamsen
2021-12-31  2:57                         ` Jose A. Ortega Ruiz
2021-12-31  1:39                       ` jao
2022-02-17 21:11                         ` Eric Abrahamsen
2022-02-18  0:22                           ` Andrew Cohen
2022-02-18  7:36                           ` Eric Abrahamsen
2022-02-18  1:20 Eric Abrahamsen

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).