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=-1.0 required=5.0 tests=MAILING_LIST_MULTI, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 15487 invoked from network); 18 Feb 2022 07:36:32 -0000 Received: from lists.gnu.org (209.51.188.17) by inbox.vuxu.org with ESMTPUTF8; 18 Feb 2022 07:36:32 -0000 Received: from localhost ([::1]:41478 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1nKxob-0006Wb-QD for ml@inbox.vuxu.org; Fri, 18 Feb 2022 02:36:29 -0500 Received: from eggs.gnu.org ([209.51.188.92]:32866) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nKxoU-0006Vh-Ik for info-gnus-english@gnu.org; Fri, 18 Feb 2022 02:36:22 -0500 Received: from ciao.gmane.io ([116.202.254.214]:53670) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nKxoQ-0002aV-Lp for info-gnus-english@gnu.org; Fri, 18 Feb 2022 02:36:20 -0500 Received: from list by ciao.gmane.io with local (Exim 4.92) (envelope-from ) id 1nKxoM-0005ak-KZ for info-gnus-english@gnu.org; Fri, 18 Feb 2022 08:36:14 +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 23:36:09 -0800 Message-ID: <877d9socd2.fsf@ericabrahamsen.net> 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:Lx7wb4BVEMP9xtkZK2fXJK0jsaU= 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" Eric Abrahamsen writes: > 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? Okay, after some hairy off-list debugging, I believe everything should be sorted and working okay. Jose, next time you update Emacs, would you give it a whirl? Eric