Eric Abrahamsen <[email protected]> writes: > "Jose A. Ortega Ruiz" <[email protected]> writes: > >> On Tue, Dec 21 2021, Andrew Cohen wrote: >> >>>>>>>> "dal-blazej" == dal-blazej <[email protected]> writes: >>> >>> [...] >>> >>> dal-blazej> To reproduce the issue : >>> >>> dal-blazej> 1. In the *server* buffer, use >>> dal-blazej> `gnus-group-read-ephemeral-search-group' with the query >>> dal-blazej> "from:[email protected]" >>> >>> dal-blazej> 2. The first search succeed ; *in the ephemeral search >>> dal-blazej> buffer*, now use `gnus-summary-refer-thread' on an >>> dal-blazej> article. I get: (wrong-type-argument listp "") >>> >>> I don't know if this is related but I just fixed a rather rare bug in >>> thread referral on master (it happens when the subject of the message on >>> which you initiate the thread referral is nearly empty). >>> >>> You might give this a try to see if it fixes your problem. >> >> I've just been able to reproduce the problem in latest master, so i am >> afraid the answer is no :) This is the beginning of the backtrace I get >> when A T in a nnselect buffer (with notmuch as its engine): >> >> Debugger entered--Lisp error: (wrong-type-argument listp "") >> alist-get(parsed-query "") >> #f(compiled-function (engine query-spec) #<bytecode >> 0x99ea4e27204d6f9>)(#<gnus-search-notmuch gnus-search-notmuch-1556d745508e> >> "") >> apply(#f(compiled-function (engine query-spec) #<bytecode >> 0x99ea4e27204d6f9>) #<gnus-search-notmuch gnus-search-notmuch-1556d745508e> >> "") >> gnus-search-make-query-string(#<gnus-search-notmuch >> gnus-search-notmuch-1556d745508e> "") >> #f(compiled-function (engine server query groups) "Run QUERY against >> SERVER using ENGINE.\nThis method is common to all indexed search >> engines.\n\nReturns a list of [group article score] vectors." >> #<bytecode 0x121b0d437dc8f9e7>)(#<gnus-search-notmuch >> gnus-search-notmuch-1556d745508e> "nnml:" "" nil) >> apply(#f(compiled-function (engine server query groups) "Run QUERY >> against SERVER using ENGINE.\nThis method is common to all indexed >> search engines.\n\nReturns a list of [group article score] vectors." >> #<bytecode 0x121b0d437dc8f9e7>) (#<gnus-search-notmuch >> gnus-search-notmuch-1556d745508e> "nnml:" "" nil)) >> #f(compiled-function (&rest cnm-args) #<bytecode >> 0x1b59543183000dee>)(#<gnus-search-notmuch >> gnus-search-notmuch-1556d745508e> "nnml:" "" nil) >> #f(compiled-function (cl--cnm engine server query groups) "Handle >> notmuch's thread-search routine." #<bytecode >> 0x1d4ee8fb5ee95069>)(#f(compiled-function (&rest cnm-args) #<bytecode >> 0x1b59543183000dee>) #<gnus-search-notmuch >> gnus-search-notmuch-1556d745508e> "nnml:" ((parsed-query (or (id . >> "CAAwB6VDPO=pT-XU8cPNfZRtxXC48LD-OXepiGejb-+QAzoymm...") (or (id . >> "t7sEZR5CwAuextCqAQyuzZ4N-BAsbVMaKTaGiG6o56GNhGyz0U...") (or (id . >> "Ivxz0PU9N9S5LLCmCuI5-UE8pt2AVamHqzLc3LibJxLdYCvo1X...") (or (id . >> "a2wBK5wGXfG6kT2lSke4Mmqc14JC2SLMqP2nsMxZAizapFFBuH...") (id . >> "V00BOpL5XPuHuS_tIuCyc-9zxFq7mR1gLUgK-BhIUZjJOXoFdr...")))))) (query . >> "id:<CAAwB6VDPO=pT-XU8cPNfZRtxXC48LD-OXepiGejb-+QAz...") (thread . t)) >> nil) > > This is a bit hard to look at, but it seems like the problem is in > notmuch's thread-specific search handling. What is supposed to happen > is that notmuch first uses those message-ids to find the messages, then > finds the thread:<thread-id> statements for all of the search results, then > does > *another* search using the thread ids from the first search. So > obviously something's going wrong with that. The relevant method is > currently line 1589 in gnus-search.el, I'm also pasting it below. Would > you mind edebugging it and stepping through to see which part exactly is > wrong? > > Thanks. > > (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))
My guess is that we need to go to point-min right here. > (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)))
