Announcements and discussions for Gnus, the GNU Emacs Usenet newsreader
 help / color / mirror / Atom feed
From: Eric Abrahamsen <eric@ericabrahamsen.net>
To: info-gnus-english@gnu.org
Subject: Re: gnus-search-engine set to gnus-search-notmuch and refer threads
Date: Wed, 22 Dec 2021 13:19:11 -0800	[thread overview]
Message-ID: <87fsqk8hio.fsf@ericabrahamsen.net> (raw)
In-Reply-To: <87k0fw8hmn.fsf@ericabrahamsen.net>

Eric Abrahamsen <eric@ericabrahamsen.net> writes:

> "Jose A. Ortega Ruiz" <jao@gnu.org> writes:
>
>> On Tue, Dec 21 2021, Andrew Cohen wrote:
>>
>>>>>>>> "dal-blazej" == dal-blazej  <dal-blazej@onenetbeyond.org> 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:jao@gnu.org"
>>>
>>>     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)))



  reply	other threads:[~2021-12-22 21:20 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <87lf1k11ed.fsf@onenetbeyond.org>
2021-11-19 19:05 ` jao
2021-12-14 21:41   ` dal-blazej
2021-12-15 17:41     ` Eric Abrahamsen
2021-12-18 23:22       ` dal-blazej
2021-12-21  5:56     ` Andrew Cohen
2021-12-22 20:56       ` Jose A. Ortega Ruiz
2021-12-22 21:16         ` Eric Abrahamsen
2021-12-22 21:19           ` Eric Abrahamsen [this message]
2021-12-22 23:01             ` Jose A. Ortega Ruiz
2021-12-23  0:30               ` Eric Abrahamsen
2021-12-23  3:34                 ` Jose A. Ortega Ruiz
2021-12-23 20:55               ` Eric Abrahamsen
2021-12-24  3:08                 ` Jose A. Ortega Ruiz
2021-12-27 21:54                   ` Jose A. Ortega Ruiz
2021-12-30 23:51                     ` Eric Abrahamsen
2021-12-31  0:07                       ` Andrew Cohen
2021-12-31  0:20                         ` Eric Abrahamsen
2021-12-31  0:37                           ` Andrew Cohen
2021-12-31  1:13                             ` Eric Abrahamsen
2021-12-31  2:57                         ` Jose A. Ortega Ruiz
2021-12-31  1:39                       ` jao
2022-02-17 21:11                         ` Eric Abrahamsen
2022-02-18  0:22                           ` Andrew Cohen
2022-02-18  7:36                           ` Eric Abrahamsen
2022-02-18  1:20 Eric Abrahamsen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87fsqk8hio.fsf@ericabrahamsen.net \
    --to=eric@ericabrahamsen.net \
    --cc=info-gnus-english@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).