From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-3.3 required=5.0 tests=FAKE_REPLY_C, MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 2497 invoked from network); 18 Feb 2022 01:20:52 -0000 Received: from lists.gnu.org (209.51.188.17) by inbox.vuxu.org with ESMTPUTF8; 18 Feb 2022 01:20:52 -0000 Received: from localhost ([::1]:42324 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1nKrx4-0008Ly-FY for ml@inbox.vuxu.org; Thu, 17 Feb 2022 20:20:50 -0500 Received: from eggs.gnu.org ([209.51.188.92]:38822) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nKrx1-0008LX-BG for info-gnus-english@gnu.org; Thu, 17 Feb 2022 20:20:47 -0500 Received: from ciao.gmane.io ([116.202.254.214]:46150) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nKrwz-00010q-6C for info-gnus-english@gnu.org; Thu, 17 Feb 2022 20:20:46 -0500 Received: from list by ciao.gmane.io with local (Exim 4.92) (envelope-from ) id 1nKrww-0000Xh-LN for info-gnus-english@gnu.org; Fri, 18 Feb 2022 02:20:42 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: info-gnus-english@gnu.org From: Eric Abrahamsen Subject: Re: gnus-search-engine set to gnus-search-notmuch and refer threads Date: Thu, 17 Feb 2022 17:20:32 -0800 Message-ID: <874k4xq8bj.fsf@ericabrahamsen.net> Mime-Version: 1.0 Content-Type: text/plain User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) Cancel-Lock: sha1:V5rqVwTIOeUmFcit4FOdcxkRslk= Received-SPF: pass client-ip=116.202.254.214; envelope-from=gegu-info-gnus-english@m.gmane-mx.org; helo=ciao.gmane.io X-Spam_score_int: -1 X-Spam_score: -0.2 X-Spam_bar: / X-Spam_report: (-0.2 / 5.0 requ) BAYES_00=-1.9, FAKE_REPLY_C=1.486, HEADER_FROM_DIFFERENT_DOMAINS=0.249, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=no autolearn_force=no X-Spam_action: no action X-BeenThere: info-gnus-english@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Announcements and discussions for GNUS, the GNU Emacs Usenet newsreader \(in English\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: info-gnus-english-bounces+ml=inbox.vuxu.org@gnu.org Sender: "info-gnus-english" Andrew Cohen writes: >>>>>> "EA" == Eric Abrahamsen 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