From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/87485 Path: news.gmane.org!.POSTED!not-for-mail From: Eric Abrahamsen Newsgroups: gmane.emacs.gnus.general Subject: Re: Testers wanted: New gnus backend nnselect Date: Tue, 25 Apr 2017 08:33:30 -0700 Message-ID: <8737cwa4dx.fsf@ericabrahamsen.net> References: <87pog233uy.fsf@hanan> <87r30h5xzt.fsf@ericabrahamsen.net> <871sshcppr.fsf@hanan> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1493134465 8388 195.159.176.226 (25 Apr 2017 15:34:25 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 25 Apr 2017 15:34:25 +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+m35702@lists.math.uh.edu Tue Apr 25 17:34:22 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 1d32Tt-00025U-G6 for ding-account@gmane.org; Tue, 25 Apr 2017 17:34:21 +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 a6a57ed6-29cc-11e7-b087-b499baabecb2; Tue, 25 Apr 2017 15:34:20 +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 1d32TJ-0006Vx-Iw; Tue, 25 Apr 2017 10:33:45 -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 1d32TG-0006VL-M7 for ding@lists.math.uh.edu; Tue, 25 Apr 2017 10:33:42 -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 1d32TF-0000IC-Fy for ding@lists.math.uh.edu; Tue, 25 Apr 2017 10:33:42 -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 1d32TE-0005S3-42 for ding@gnus.org; Tue, 25 Apr 2017 17:33:40 +0200 Original-Received: from list by blaine.gmane.org with local (Exim 4.84_2) (envelope-from ) id 1d32T7-00013e-3L for ding@gnus.org; Tue, 25 Apr 2017 17:33:33 +0200 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 54 Original-X-Complaints-To: usenet@blaine.gmane.org Cancel-Lock: sha1:Bd/a6Dt4cZhC/VSjUIDTDH/IBns= List-ID: Precedence: bulk Xref: news.gmane.org gmane.emacs.gnus.general:87485 Archived-At: Andrew Cohen writes: [...] > Great! But there is one quirk to keep in mind. If you start in a > "normal" group (like one with an imap backend) you can't (easily) insert > articles from other groups into the same summary buffer. If you look at > nnimap-request-thread you will notice that if > gnus-refer-thread-use-search is nil then only the current group is > probed for thread articles. But if its non-nil then it defers to > nnselect-search-thread which creates a NEW nnselect ephemeral buffer to > allow the results to cross groups. You can probably implement this in > new nnfoo-request-thread methods for all the backends. > > The function nnselect-request-thread is called only when referring a > thread from an nnselect group. The only way it is engine specific right > now is in the construction of the search query string > (nnimap-make-thread-query). So you could provide a function > nnir-make-thread-query (or better yet encapsulate the whole nnir related > stuff in nnselect-request-thread into a function like nnir-refer-thread) > and this would make the function fully universal (and keep all the > search-related junk in nnir where it belongs) > > Then this same function can be used in nnselect-search-thread, > easy-peasy. > > Sorry, re-reading the above paragraphs I might not have been clear (but > maybe I was?) And I guess I'm suggesting the function should be called > gnus-refer-thread. > > And of course I meant gnus-search-refer-thread :) My eyes did cross for a second there, reading the above :) But I think I've got the basics, and will have a look at the details over the next week. My goal is definitely to make the search code completely backend agnostic, so that all nnselect-request-thread has to do is call a single function. What I'm thinking now is to make thread search a part of the basic query language. In fact, there would be a few "meta search terms" that could be specified along with the base query. "thread:t" would be one of them, along with "count:t", "limit:NN", and "sort:," (obviously they can't all be used in conjunction). The syntax for searching for a single message's thread would be "thread:t id:". That would get parsed into: ('nnir-query-spec ('query ((id . ""))) ('thread t)) It would be up to the search engines to make sense of that. Eric