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.6 required=5.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED, RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,UNPARSEABLE_RELAY autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 6552 invoked from network); 31 Dec 2021 01:40:23 -0000 Received: from lists.gnu.org (209.51.188.17) by inbox.vuxu.org with ESMTPUTF8; 31 Dec 2021 01:40:23 -0000 Received: from localhost ([::1]:53532 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1n36u5-0001YN-H9 for ml@inbox.vuxu.org; Thu, 30 Dec 2021 20:40:21 -0500 Received: from eggs.gnu.org ([209.51.188.92]:47592) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1n36tm-0001YC-Tn for info-gnus-english@gnu.org; Thu, 30 Dec 2021 20:40:02 -0500 Received: from [2001:470:142:3::e] (port=35832 helo=fencepost.gnu.org) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1n36tm-0005wH-DA; Thu, 30 Dec 2021 20:40:02 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-Version:Date:References:In-Reply-To:Subject:To: From; bh=2x9zaCj6B95isLYyZYgHjQm/Ilmkgh5W4k0Y5cMUa4A=; b=sPEqS81kcgRFwGGRgBvx qUuUHMRX9fbindrc9sWg0zqVpaPN+vtRSgjY2CjIzmFQpvXgxApdIbA8t+ZY+Q7d7wHjMqJtuQ6CX h/PwvAc7Nb0c8qIVq+gd4xzTaVaJkawGfA2dD6NSd9OvaYB3/iZ/1yOv5UUvc2X0j5uogqlPscLAI H+maViWtf58N+qMwEH3ATYCSl2tj9SAgPJy0xN0gbPjaPBx4BhLVUK6MwymC/H9OmQR9VjI8tOdZm HO4t1EjFfX63X4gyS1cqv6mPmMbbInjgrDnkfShjkqH+x//US17j81n0aRb3h5BoMuWspewExJ0p0 EbA8S/m1+lLv2A==; Received: from 211.68.17.95.dynamic.jazztel.es ([95.17.68.211]:47424 helo=rivendell.localdomain) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1n36tm-0006uk-Gy; Thu, 30 Dec 2021 20:40:02 -0500 Received: from localhost (rivendell.localdomain [local]) by rivendell.localdomain (OpenSMTPD) with ESMTPA id c4926d05; Fri, 31 Dec 2021 01:39:58 +0000 (UTC) From: jao To: Eric Abrahamsen Subject: Re: gnus-search-engine set to gnus-search-notmuch and refer threads In-Reply-To: <87czldzm6t.fsf@ericabrahamsen.net> (Eric Abrahamsen's message of "Thu, 30 Dec 2021 15:51:06 -0800") References: <87czldzm6t.fsf@ericabrahamsen.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) X-Attribution: jao X-Clacks-Overhead: GNU Terry Pratchett X-URL: Date: Fri, 31 Dec 2021 01:39:58 +0000 Message-ID: <87ee5tv9g1.fsf@gnus.jao.io> MIME-Version: 1.0 Content-Type: text/plain 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: info-gnus-english@gnu.org Errors-To: info-gnus-english-bounces+ml=inbox.vuxu.org@gnu.org Sender: "info-gnus-english" 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?) thanks a lot! jao -- Beauty is the purgation of superfluities. -Michelangelo Buonarroti (1475-1564)