From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/87475 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: Sun, 23 Apr 2017 16:22:47 -0700 Message-ID: <878tmq675k.fsf@ericabrahamsen.net> References: <87zif930mt.fsf@ericabrahamsen.net> <871ssji6b2.fsf@uwo.ca> <8760hv6nzu.fsf@ericabrahamsen.net> <878tmrf1jr.fsf@uwo.ca> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1492989849 17334 195.159.176.226 (23 Apr 2017 23:24:09 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 23 Apr 2017 23:24:09 +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+m35693@lists.math.uh.edu Mon Apr 24 01:24:05 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 1d2QrK-0004LI-Oc for ding-account@gmane.org; Mon, 24 Apr 2017 01:24:02 +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 f1a1edb3-287b-11e7-b087-b499baabecb2; Sun, 23 Apr 2017 23:24:06 +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 1d2Qqg-0004xi-9N; Sun, 23 Apr 2017 18:23:22 -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 1d2Qqc-0004x5-Q1 for ding@lists.math.uh.edu; Sun, 23 Apr 2017 18:23:18 -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 1d2Qqb-0002nS-O8 for ding@lists.math.uh.edu; Sun, 23 Apr 2017 18:23:18 -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 1d2Qqa-0004Jf-BD for ding@gnus.org; Mon, 24 Apr 2017 01:23:16 +0200 Original-Received: from list by blaine.gmane.org with local (Exim 4.84_2) (envelope-from ) id 1d2QqS-0003KE-LC for ding@gnus.org; Mon, 24 Apr 2017 01:23:08 +0200 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 46 Original-X-Complaints-To: usenet@blaine.gmane.org Cancel-Lock: sha1:QoNazWUAY9a36jwjZqg55MtQkQ8= List-ID: Precedence: bulk Xref: news.gmane.org gmane.emacs.gnus.general:87475 Archived-At: Dan Christensen writes: > On Apr 23, 2017, Eric Abrahamsen wrote: > >> Dan Christensen writes: >> >>> Will mairix be supported? >> >> Sure! At least, I think so -- I'm not clear why nnmairix is its own >> server, rather than being an nnir engine. I think if it's used in raw >> mode it should work just like the other engines. At any rate, as many >> engines as possible should be supported. > > I don't know much about how things work in the background, but mairix > produces a maildir of results, so maybe that's why it is handled > specially. One of the great things about it is that it can already > combine results from maildirs and mboxes, so it already works across > (some) servers. > > But from a configuration perspective, I've often had trouble with > nnmairix, so it would be great if it could be fitted into a more > general, stable set-up. Anything you can remember about these troubles would be helpful. And I hope you'll be willing to test the mairix support when it's ready (I've already added the backend, but the query transformation will take a bit more work). > Maybe mairix's raw mode that you mention would help with this? But > then Gnus would have to work backwords from the maildir paths and > nnfolder paths + position in file to figure out the messages... Gnus already does that for *all* of the other locally-indexed search engines, so that's no big deal :) >>> How do you handle differing capabilities of the search backends? > > [...] > >> What do you think? > > Sounds reasonable, especially if it is documented and maybe displays > warnings/messages in some cases. Yup, it might be nice to just drop a message saying that some search terms were ignored, that's a good idea.