From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/87531 Path: news.gmane.org!.POSTED!not-for-mail From: Eric Abrahamsen Newsgroups: gmane.emacs.gnus.general Subject: Re: [RFC] Gnus generalized search, part II Date: Sat, 29 Apr 2017 22:13:49 -0700 Message-ID: <87r30aqxyq.fsf@ericabrahamsen.net> References: <87zif930mt.fsf@ericabrahamsen.net> <87shkx5z17.fsf@ericabrahamsen.net> <87zif3fupv.fsf@hanan> <87h91b3z2m.fsf@ericabrahamsen.net> <87tw5aztpy.fsf@ericabrahamsen.net> <87wpa6iif7.fsf@hanan> <87o9vh90cy.fsf@ericabrahamsen.net> <87r30dz618.fsf@hanan> <87y3uk2xxz.fsf@ericabrahamsen.net> <87efwc2r1x.fsf@ericabrahamsen.net> <87y3ukf716.fsf@hanan> <87wpa3hnll.fsf@ericabrahamsen.net> <87vapnpnam.fsf@hanan> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1493529333 31901 195.159.176.226 (30 Apr 2017 05:15:33 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 30 Apr 2017 05:15:33 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.0.50 (gnu/linux) To: ding@gnus.org Original-X-From: ding-owner+m35746@lists.math.uh.edu Sun Apr 30 07:15:29 2017 Return-path: Envelope-to: ding-account@gmane.org Original-Received: from mxfilter-048035.atla03.us.yomura.com ([107.189.48.35]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1d4hCi-0008BO-Pp for ding-account@gmane.org; Sun, 30 Apr 2017 07:15:28 +0200 X-Yomura-MXScrub: 1.0 Original-Received: from lists1.math.uh.edu (unknown [129.7.128.208]) by mxfilter-048035.atla03.us.yomura.com (Halon) with ESMTPS id 082e5bed-2d64-11e7-b087-b499baabecb2; Sun, 30 Apr 2017 05:15:31 +0000 (UTC) Original-Received: from localhost ([127.0.0.1] helo=lists.math.uh.edu) by lists1.math.uh.edu with smtp (Exim 4.87) (envelope-from ) id 1d4hBn-00018Y-DW; Sun, 30 Apr 2017 00:14:31 -0500 Original-Received: from mx2.math.uh.edu ([129.7.128.33]) by lists1.math.uh.edu with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.87) (envelope-from ) id 1d4hBh-00017y-QM for ding@lists.math.uh.edu; Sun, 30 Apr 2017 00:14:25 -0500 Original-Received: from quimby.gnus.org ([80.91.231.51]) by mx2.math.uh.edu with esmtps (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.87) (envelope-from ) id 1d4hBf-0002lU-IH for ding@lists.math.uh.edu; Sun, 30 Apr 2017 00:14:25 -0500 Original-Received: from [195.159.176.226] (helo=blaine.gmane.org) by quimby.gnus.org with esmtps (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1d4hBd-0000Cu-A6 for ding@gnus.org; Sun, 30 Apr 2017 07:14:21 +0200 Original-Received: from list by blaine.gmane.org with local (Exim 4.84_2) (envelope-from ) id 1d4hBU-0006nn-Kt for ding@gnus.org; Sun, 30 Apr 2017 07:14:12 +0200 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 58 Original-X-Complaints-To: usenet@blaine.gmane.org Cancel-Lock: sha1:B12rUtIwigkg5gZpDohf6qndJUI= List-ID: Precedence: bulk Xref: news.gmane.org gmane.emacs.gnus.general:87531 Archived-At: Andrew Cohen writes: >>>>>> "Eric" == Eric Abrahamsen writes: > > Eric> Eric Abrahamsen writes: [...] > > [...] > > > Eric> I wonder if we have a misunderstanding... My original > Eric> assumption was that native thread searching would only be > Eric> responsible for locating the relevant messages, *not* for > Eric> creating thread structures. Ie, engines supply lists of > Eric> messages from their respective backends that they believe to > Eric> be relevant to the original list of message-ids. All those > Eric> messages get dumped in flat list into a summary buffer, and > Eric> Gnus does its usual thread construction routines. "notmuch > Eric> --thread" and "mairix --threads" return flat lists to begin > Eric> with. IMAP THREAD returns nested lists, but I'd been assuming > Eric> that I would flatten those results out before passing them to > Eric> nnselect. > > Yes, we are on the same page. > > Eric> Each engine pretty much does the same trick of > Eric> references/in-reply-to/maybe-subject, but I have to believe > Eric> they do a more efficient job of it in their own domains. But > Eric> then we let Gnus do the final threading before presenting the > Eric> results to the user. > > > But the issue is that with email threads that span multiple servers any > given server might not know enough about the thread to return all the > relevant ids. > > Consider the current system: start with a message; find all the messages > in the current summary buffer that gnus thinks are part of a thread; > combine all of the servers that these messages come from. Now take the > initial message with its message-id and its references. Do an OR search > on all of the servers (at some time the algorithm collected all the > message-ids in all the references from all the articles in the current > summary buffer thread; I think I stopped doing that because of a bug in > gnus sparse article handling that I finally tracked down last week(!) > but I intend to put it back). Actually, sorry, I had already come around to the idea that we need to start out with a list of messages ids, not just a single one. At this point I was only saying that I'd still prefer to be using the actual "thread" commands on the various engines. I probably didn't make that clear. Rather than continuing to talk around this, maybe we should start looking at some code. Would you be willing to make a commit on the scratch/gnus-search branch, adding calls to the (still hypothetical) `gnus-search-refer-thread' function where you'd like to see them, and passing in the appropriate arguments? I can take a look at that and start working on the function itself; I'll have a better sense of how it needs to work, and can test it. What do you think?