From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/87511 Path: news.gmane.org!.POSTED!not-for-mail From: Andrew Cohen Newsgroups: gmane.emacs.gnus.general Subject: Re: [RFC] Gnus generalized search, part II Date: Fri, 28 Apr 2017 09:15:31 +0800 Organization: Boston University Message-ID: <87r30dz618.fsf@hanan> 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> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1493342199 1409 195.159.176.226 (28 Apr 2017 01:16:39 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 28 Apr 2017 01:16:39 +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+m35726@lists.math.uh.edu Fri Apr 28 03:16:36 2017 Return-path: Envelope-to: ding-account@gmane.org Original-Received: from mxfilter-048034.atla03.us.yomura.com ([107.189.48.34]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1d3uWQ-0000Ep-7K for ding-account@gmane.org; Fri, 28 Apr 2017 03:16:34 +0200 X-Yomura-MXScrub: 1.0 Original-Received: from lists1.math.uh.edu (unknown [129.7.128.208]) by mxfilter-048034.atla03.us.yomura.com (Halon) with ESMTPS id 53766109-2bb0-11e7-8ed1-b499baa2b07a; Fri, 28 Apr 2017 01:16:37 +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 1d3uVl-000282-N5; Thu, 27 Apr 2017 20:15:53 -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 1d3uVh-000276-By for ding@lists.math.uh.edu; Thu, 27 Apr 2017 20:15:49 -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 1d3uVg-0004Uy-5f for ding@lists.math.uh.edu; Thu, 27 Apr 2017 20:15:49 -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 1d3uVe-0000Ew-QN for ding@gnus.org; Fri, 28 Apr 2017 03:15:46 +0200 Original-Received: from list by blaine.gmane.org with local (Exim 4.84_2) (envelope-from ) id 1d3uVV-0007q5-TH for ding@gnus.org; Fri, 28 Apr 2017 03:15:37 +0200 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 64 Original-X-Complaints-To: usenet@blaine.gmane.org Cancel-Lock: sha1:WsBZsX4HZGBKq7CBP3ZVuLRSQxU= List-ID: Precedence: bulk Xref: news.gmane.org gmane.emacs.gnus.general:87511 Archived-At: >>>>> "Eric" == Eric Abrahamsen writes: Eric> Andrew Cohen writes: >>>>>>> "Eric" == Eric Abrahamsen writes: >> Eric> Eric Abrahamsen writes: [...] Eric> Ah, okay. I don't see nnselect-summary-line-format getting Eric> applied anywhere though -- the main thing I was interested in Eric> was seeing original group names. Hmm, working fine for me. Can you try with just a checkout of feature/gnus-select and see if it works? Ohh, uhm, forgot to mention:) You have to put the spec in the gnus-summary-line-format variable instead of the old nnir specific one (which has gone away). This spec will be happily ignored in normal groups (%g for short group name and %G for the full name). [...] Eric> Actually, if I'm understanding this correctly, all you'd need Eric> to do is run a regular search with gnus-search-run-query. In Eric> the search-query-spec, put a (thread t) key alongside the Eric> query key. So the query spec would look like: Eric> '((query "id:") (thread t)) Eric> That will be enough to tell the search engines to do whatever Eric> they have to do to produce a whole thread. (Note this code Eric> isn't actually written yet, but that's how it will work.) I don't think this is general enough. Some backends don't allow native thread searching so we have to build the list of message-ids ourselves. And for some backends the threads that are found aren't the same ones that gnus thinks of as threads (you can read the ancient discussion about why Lars chose not to use the imap thread command). So what nnselect (formerly nnir) does is to make its choice as to the message-ids in the thread and then search for these (the algorithm: start with the primary article and get its message-id and all the message-ids in its references header. Then search for all messages that have any of these ids either in their message-id or references header. Finally allow for similar subjects in threading as well. This works quite well.) If we are only passing the message-id for the primary article to gnus-search then it will have to root around to get all the other relevant info (references and subject headers of the primary article). This I think breaks the paradigm of gnus-search as just search. So my idea was to pass the full list of message-ids (and perhaps the subject) to the gnus-search function and then let it do what it wants: it could, depending on some configuration, use the native backend thread search (and ignore everything passed but the primary article message-id). Or, by default, it could do it the gnus-approved way. Best, Andy