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=MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 27350 invoked from network); 18 Feb 2022 00:23:16 -0000 Received: from lists.gnu.org (209.51.188.17) by inbox.vuxu.org with ESMTPUTF8; 18 Feb 2022 00:23:16 -0000 Received: from localhost ([::1]:56028 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1nKr3K-00045M-At for ml@inbox.vuxu.org; Thu, 17 Feb 2022 19:23:14 -0500 Received: from eggs.gnu.org ([209.51.188.92]:58812) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nKr3G-000450-7L for info-gnus-english@gnu.org; Thu, 17 Feb 2022 19:23:10 -0500 Received: from ciao.gmane.io ([116.202.254.214]:43496) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nKr3D-00017c-Rd for info-gnus-english@gnu.org; Thu, 17 Feb 2022 19:23:09 -0500 Received: from list by ciao.gmane.io with local (Exim 4.92) (envelope-from ) id 1nKr3C-00039G-20 for info-gnus-english@gnu.org; Fri, 18 Feb 2022 01:23:06 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: info-gnus-english@gnu.org From: Andrew Cohen Subject: Re: gnus-search-engine set to gnus-search-notmuch and refer threads Date: Fri, 18 Feb 2022 08:22:55 +0800 Message-ID: <874k4xrpk0.fsf@ust.hk> References: <87czldzm6t.fsf@ericabrahamsen.net> <87ee5tv9g1.fsf@gnus.jao.io> <87a6epqjts.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:/sFnPf7m6yb3BintyY7NSAJSY90= 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: -16 X-Spam_score: -1.7 X-Spam_bar: - X-Spam_report: (-1.7 / 5.0 requ) BAYES_00=-1.9, 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" >>>>> "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. 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