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.4 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FAKE_REPLY_C,MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED, RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 24924 invoked from network); 30 Dec 2021 23:51:24 -0000 Received: from lists.gnu.org (209.51.188.17) by inbox.vuxu.org with ESMTPUTF8; 30 Dec 2021 23:51:24 -0000 Received: from localhost ([::1]:54030 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1n35Cc-000816-NM for ml@inbox.vuxu.org; Thu, 30 Dec 2021 18:51:22 -0500 Received: from eggs.gnu.org ([209.51.188.92]:58876) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1n35CZ-00080w-1N for info-gnus-english@gnu.org; Thu, 30 Dec 2021 18:51:19 -0500 Received: from mail.ericabrahamsen.net ([52.70.2.18]:54578) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1n35CW-0006fg-TH; Thu, 30 Dec 2021 18:51:18 -0500 Received: from localhost (c-71-197-232-41.hsd1.wa.comcast.net [71.197.232.41]) (Authenticated sender: eric@ericabrahamsen.net) by mail.ericabrahamsen.net (Postfix) with ESMTPSA id 285C7FA095; Thu, 30 Dec 2021 23:51:08 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericabrahamsen.net; s=mail; t=1640908268; bh=264lz1g6QD5Gye+ZxwMIlnQdE6iGqNohaJ66TeWuEdg=; h=From:To:Cc:Subject:Date:In-Reply-To:From; b=dq1PhWxud4rDZWEUk01K4tJnM9z+iA4n7ciYFAXaq8Lo+sXFv1zlsoOo4h8CnXDNg yi4Oma5Fq3amdC7ZVVlRmt6oNHgaYjcnGv+qkL+dvU7l7m9uPOdQgVaCVWaF/OI7Yj nmoIFZiyfZvk5YwBHGAyxk5AbH6krlNYl63nuqBM= From: Eric Abrahamsen To: "Jose A. Ortega Ruiz" Subject: Re: gnus-search-engine set to gnus-search-notmuch and refer threads Date: Thu, 30 Dec 2021 15:51:06 -0800 In-Reply-To: <877dbp67dn.fsf@gnus.jao.io> (Jose A. Ortega Ruiz's message of "Mon, 27 Dec 2021 21:54:44 +0000") Message-ID: <87czldzm6t.fsf@ericabrahamsen.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" Received-SPF: pass client-ip=52.70.2.18; envelope-from=eric@ericabrahamsen.net; helo=mail.ericabrahamsen.net X-Spam_score_int: -9 X-Spam_score: -1.0 X-Spam_bar: - X-Spam_report: (-1.0 / 5.0 requ) DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FAKE_REPLY_C=1.486, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=unavailable 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: info-gnus-english@gnu.org Errors-To: info-gnus-english-bounces+ml=inbox.vuxu.org@gnu.org Sender: "info-gnus-english" --=-=-= Content-Type: text/plain "Jose A. Ortega Ruiz" writes: > Hi again, > > So, summing up what we have so far (patch attached), the effect of these > changes is to make the errors go away, but i'm not sure if the behaviour > is expected: with the patch applied, A T will "work" for me in an > nnselect group, with the caveat that, when gnus-refer-thread-use-search > is t (or when calling gnus-refer-thread with C-u otherwise), the result > is limited to the email already present in the nnselect group... that > might be expected, in which case i think the patch can be applied (it's > basically what you already propose, Eric, except it constructs the query > as an alist). 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. - 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). - 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. Thanks again, Eric --=-=-= Content-Type: text/x-patch Content-Disposition: attachment; filename=notmuchthreads.diff diff --git a/lisp/gnus/gnus-search.el b/lisp/gnus/gnus-search.el index d64c0cb90c..4fb1fa3ec3 100644 --- a/lisp/gnus/gnus-search.el +++ b/lisp/gnus/gnus-search.el @@ -1352,7 +1352,10 @@ gnus-search-indexed-parse-output server query &optional groups) (let ((prefix (or (slot-value engine 'remove-prefix) "")) - (groups (mapcar #'gnus-group-short-name groups)) + (groups (unless (alist-get 'thread query) + ;; If we're searching threads, return messages from + ;; all groups. + (mapcar #'gnus-group-short-name groups))) artlist article group) (goto-char (point-min)) ;; Prep prefix, we want to at least be removing the root @@ -1529,6 +1532,17 @@ gnus-search-transform (_query null)) "*") +(cl-defmethod gnus-search-make-query-string :around ((_engine gnus-search-notmuch) + query-spec) + "Use Notmuch's thread:{} syntax. +This packs the whole original query into , then +returns all threads containing all matched messages." + (let ((query-string (cl-call-next-method)) + (threadp (alist-get 'thread query-spec))) + (if threadp + (format "thread:{%s}" query-string) + query-string))) + (cl-defmethod gnus-search-transform-expression ((engine gnus-search-notmuch) (expr (head near))) (format "%s near %s" @@ -1586,55 +1600,22 @@ gnus-search-transform-expression (format "date:%s.." (notmuch-date (cdr expr)))) (t (ignore-errors (cl-call-next-method)))))) -(cl-defmethod gnus-search-run-search :around ((engine gnus-search-notmuch) - server query groups) - "Handle notmuch's thread-search routine." - ;; Notmuch allows for searching threads, but only using its own - ;; thread ids. That means a thread search is a \"double-bounce\": - ;; once to find the relevant thread ids, and again to find the - ;; actual messages. This method performs the first \"bounce\". - (if (alist-get 'thread query) - (with-slots (program proc-buffer) engine - (let* ((qstring - (gnus-search-make-query-string engine query)) - (cp-list (gnus-search-indexed-search-command - engine qstring query groups)) - thread-ids proc) - (set-buffer proc-buffer) - (erase-buffer) - (setq proc (apply #'start-process (format "search-%s" server) - proc-buffer program cp-list)) - (while (process-live-p proc) - (accept-process-output proc)) - (while (re-search-forward "^thread:\\([^ ]+\\)" (point-max) t) - (push (match-string 1) thread-ids)) - (cl-call-next-method - engine server - ;; Completely replace the query with our new thread-based one. - (mapconcat (lambda (thrd) (concat "thread:" thrd)) - thread-ids " or ") - nil))) - (cl-call-next-method engine server query groups))) - (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)) - (thread (alist-get 'thread query))) + (let ((limit (alist-get 'limit query))) (with-slots (switches config-file) engine - `(,(format "--config=%s" config-file) - "search" - ,(if thread - "--output=threads" - "--output=files") - "--duplicate=1" ; I have found this necessary, I don't know why. - ,@switches - ,(if limit (format "--limit=%d" limit) "") - ,qstring - )))) + (append + (list (format "--config=%s" config-file) + "search" + "--output=files" + "--duplicate=1") + (when limit (list (format "--limit=%d" limit))) + switches + (list qstring))))) ;;; Mairix interface --=-=-=--