From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/87481 Path: news.gmane.org!.POSTED!not-for-mail From: Andrew Cohen Newsgroups: gmane.emacs.gnus.general Subject: Re: Testers wanted: New gnus backend nnselect Date: Tue, 25 Apr 2017 08:09:52 +0800 Organization: Boston University Message-ID: <871sshcppr.fsf@hanan> References: <87pog233uy.fsf@hanan> <87r30h5xzt.fsf@ericabrahamsen.net> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1493079101 4210 195.159.176.226 (25 Apr 2017 00:11:41 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 25 Apr 2017 00:11:41 +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+m35698@lists.math.uh.edu Tue Apr 25 02:11:38 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 1d2o4v-000112-Nz for ding-account@gmane.org; Tue, 25 Apr 2017 02:11:37 +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 c1626302-294b-11e7-b087-b499baabecb2; Tue, 25 Apr 2017 00:11:40 +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 1d2o46-0007rL-VK; Mon, 24 Apr 2017 19:10:47 -0500 Original-Received: from mx1.math.uh.edu ([129.7.128.32]) by lists1.math.uh.edu with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.87) (envelope-from ) id 1d2o43-0007qb-M5 for ding@lists.math.uh.edu; Mon, 24 Apr 2017 19:10:43 -0500 Original-Received: from quimby.gnus.org ([80.91.231.51]) by mx1.math.uh.edu with esmtps (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.87) (envelope-from ) id 1d2o42-0000F8-45 for ding@lists.math.uh.edu; Mon, 24 Apr 2017 19:10:43 -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 1d2o3U-0003Nq-EK for ding@gnus.org; Tue, 25 Apr 2017 02:10:15 +0200 Original-Received: from list by blaine.gmane.org with local (Exim 4.84_2) (envelope-from ) id 1d2o3M-0007Vr-Aj for ding@gnus.org; Tue, 25 Apr 2017 02:10:00 +0200 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 75 Original-X-Complaints-To: usenet@blaine.gmane.org Cancel-Lock: sha1:/Txe/1bcVus6d40iGU+buYKerhY= List-ID: Precedence: bulk Xref: news.gmane.org gmane.emacs.gnus.general:87481 Archived-At: >>>>> "Eric" == Eric Abrahamsen writes: Eric> Andrew Cohen writes: >> TLDR: Please test the new feature found on the git repository at >> feature/gnus-select. Eric> Very cool! Later this week I'll make another copy of the Eric> search-language branch that's rebased onto this one. Eric> [...] [...] Eric> Once this has landed, I hope we can rename nnir.el to Eric> gnus-search.el, and drop the "nnir" term altogether. Yes, that's what I meant when I said there was a lot of renaming to do:) [...] Eric> I've started on a gnus-search-thread method for the search Eric> engines -- in fact, the majority of them can already handle Eric> searching by thread. Ideally `nnselect-request-thread' could Eric> then become engine-agnostic, and only punt if the engine in Eric> question doesn't implement the `gnus-search-thread' method. 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. [...] Eric> I think that, to maximize chances of people actually testing Eric> this, it would be best to provide a ready-made Eric> `gnus-group-make-persistent-search-group' function (or call it Eric> whatever), and give it a keybinding. Say: But it has a keybinding: the usual one! "G m" (gnus-group-make-group):) OK, OK, it will only take a second to make a dedicated function. But at some point I hope people go beyond searching in the testing. [...] Best, Andy