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 3087 invoked from network); 17 Feb 2022 21:12:21 -0000 Received: from lists.gnu.org (209.51.188.17) by inbox.vuxu.org with ESMTPUTF8; 17 Feb 2022 21:12:21 -0000 Received: from localhost ([::1]:50616 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1nKo4Y-00016u-D3 for ml@inbox.vuxu.org; Thu, 17 Feb 2022 16:12:18 -0500 Received: from eggs.gnu.org ([209.51.188.92]:47278) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nKo4U-00016l-Tf for info-gnus-english@gnu.org; Thu, 17 Feb 2022 16:12:14 -0500 Received: from ciao.gmane.io ([116.202.254.214]:54750) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nKo4T-0004Ya-1C for info-gnus-english@gnu.org; Thu, 17 Feb 2022 16:12:14 -0500 Received: from list by ciao.gmane.io with local (Exim 4.92) (envelope-from ) id 1nKo4Q-00080x-3a for info-gnus-english@gnu.org; Thu, 17 Feb 2022 22:12:10 +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 13:11:59 -0800 Message-ID: <87a6epqjts.fsf@ericabrahamsen.net> References: <87czldzm6t.fsf@ericabrahamsen.net> <87ee5tv9g1.fsf@gnus.jao.io> 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:gKvxJg3gS4H4DyDVStfkT8jqIoI= 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: , Cc: Andrew Cohen Errors-To: info-gnus-english-bounces+ml=inbox.vuxu.org@gnu.org Sender: "info-gnus-english" jao writes: > On Thu, Dec 30 2021, Eric Abrahamsen wrote: > > > [...] > >> Okay, here goes the next try. A few things to note: >> >> - I realized notmuch already has a "thread:{}" syntax that >> does the double search I was doing in elisp, so now we just use that instead. > > makes sense. > >> - In all my testing I couldn't see that having "duplicate=1" on thread >> searches causes any problems, so I've taken it off. Can you please >> doublecheck this? If it's still mucking it up for you, I'll put it >> back in. I wish I really understood what the problem is (I think it >> has to do with notmuch potentially storing the same message in >> multiple locations, using symlinks). > > hmm, are you sure you've removed it? i can see, after applying your > diff, at least for files searches: > > (cl-defmethod gnus-search-indexed-search-command ((engine gnus-search-notmuch) > (qstring string) > query &optional _groups) > ;; Theoretically we could use the GROUPS parameter to pass a > ;; --folder switch to notmuch, but I'm not confident of getting the > ;; format right. > (let ((limit (alist-get 'limit query))) > (with-slots (switches config-file) engine > (append > (list (format "--config=%s" config-file) > "search" > "--output=files" > "--duplicate=1") > (when limit (list (format "--limit=%d" limit))) > switches > (list qstring))))) > > at any rate, i had already tried searches without it in my patched > version and haven't seen any adverse effects. my understanding is that > notmuch is clever enough to detect duplicate messages with different > filenames . > > >> - The search result filtration now won't filter on group names if the >> search is a thread search. This should resolve the issue you were >> seeing where "A T" would only search within the group you had searched >> in to begin with. I guess I think that an explicit thread search by >> the user should result in a full scan of the server. We can see if >> that surprises/annoys anyone, though. > > the behaviour for me is the same as with my previous patch: A T stays in > the nnselect group. a thing to notice is that, in general, there is no > single "the group you had searched in to begin width" (pretty often, i > do searches accross all my nnml groups, of which i have plenty)... a > full scan of the server is, i think, precisely what a notmuch user would > expect :) (but i don't know if this is really supposed to work for > gnus-search: in general, collecting all messages of a thread will return > messages from a list of different gnus groups: should we be able to show > all of them in an ephemeral group then?). > > be it as it may, even with the full original thread belonging to a > single nnml group, A T is leaving me in nnselect with only the messages > that were already there (i.e., it's not equivalent to A W followed by A > T... but then again, maybe it's not supposed to be?) I can't believe how long this is taking me... I was confusing myself because there are two separate problems: notmuch thread searching was simply broken, and referring a thread from within an nnselect group only finds messages already in that select group. I've pushed a patch that should simply get thread searching into a working state (notmuch's "thread{}" syntax turned out to be more complicated and less useful than I thought, so I dropped it). Next, I think it's a reasonable design decision to say that referring a thread from within an nnselect group should search that group's constituent groups, not the group itself. What I'm seeing is that nnselect actually does that (if we're using search for thread-referral, it nixes out the group argument and searches the whole original server(s)), but then an error is raised later on, when we try to fetch the headers (line 656). I can see that all the thread article numbers are returned correctly, but then when we get to `gnus-fetch-headers' I get an args-out-of-range error, it looks like because we're looking for the index of an article number in the original (smaller) list of newsgroup headers. This was referring a thread from a summary buffer that contained only a single message. Andy, does that sound familiar? One other bug I'm not sure what to do with: notmuch only accepts message-ids as search terms *without* the angle brackets. If the user is using unparsed (raw) queries, presumably they know not to include angle brackets. If they're using parsed queries, the parsing process strips any brackets out. But if they're using raw queries *and* refer threads, nnselect passes in the thread search query with the angle brackets (reasonable, since that's how `mail-header-id' and friends return them). But that causes failure in the subsequent notmuch search. I don't want to special-case this, but on the other hand if all other search engines are also able to handle the no-brackets case, maybe we could just always strip the brackets? Eric