From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/83937 Path: news.gmane.org!not-for-mail From: Eric Abrahamsen Newsgroups: gmane.emacs.gnus.general Subject: Re: Create a group from a list of message-ids Date: Fri, 29 Nov 2013 10:41:22 +0700 Message-ID: <87eh5zg9i5.fsf@ericabrahamsen.net> References: <87vbzjs5fk.fsf@gmail.com> <844n71b5nh.fsf@davestoy.home> <871u24c18u.fsf@gmail.com> <87d2lo4zy7.fsf@ericabrahamsen.net> <87siukalp5.fsf@gmail.com> <87txf01uum.fsf@ericabrahamsen.net> <87d2loa812.fsf@gmail.com> <87d2lo1ozp.fsf@ericabrahamsen.net> <877gbwlc3p.fsf@ft.bewatermyfriend.org> <87siujyfh0.fsf@ericabrahamsen.net> <87zjooivk4.fsf@gmail.com> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Trace: ger.gmane.org 1385696446 18877 80.91.229.3 (29 Nov 2013 03:40:46 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 29 Nov 2013 03:40:46 +0000 (UTC) To: ding@gnus.org Original-X-From: ding-owner+M32192@lists.math.uh.edu Fri Nov 29 04:40:48 2013 Return-path: Envelope-to: ding-account@gmane.org Original-Received: from util0.math.uh.edu ([129.7.128.18]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1VmEwh-00011p-9C for ding-account@gmane.org; Fri, 29 Nov 2013 04:40:47 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.math.uh.edu) by util0.math.uh.edu with smtp (Exim 4.63) (envelope-from ) id 1VmEvw-000792-St; Thu, 28 Nov 2013 21:40:00 -0600 Original-Received: from mx1.math.uh.edu ([129.7.128.32]) by util0.math.uh.edu with esmtps (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from ) id 1VmEvv-00078s-F0 for ding@lists.math.uh.edu; Thu, 28 Nov 2013 21:39:59 -0600 Original-Received: from quimby.gnus.org ([80.91.231.51]) by mx1.math.uh.edu with esmtps (TLSv1:AES128-SHA:128) (Exim 4.76) (envelope-from ) id 1VmEvt-0008PY-T7 for ding@lists.math.uh.edu; Thu, 28 Nov 2013 21:39:58 -0600 Original-Received: from plane.gmane.org ([80.91.229.3]) by quimby.gnus.org with esmtp (Exim 4.80) (envelope-from ) id 1VmEvr-00040S-Mr for ding@gnus.org; Fri, 29 Nov 2013 04:39:55 +0100 Original-Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1VmEvq-0000R3-HV for ding@gnus.org; Fri, 29 Nov 2013 04:39:54 +0100 Original-Received: from 223.204.249.82 ([223.204.249.82]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 29 Nov 2013 04:39:54 +0100 Original-Received: from eric by 223.204.249.82 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 29 Nov 2013 04:39:54 +0100 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 104 Original-X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: 223.204.249.82 User-Agent: Gnus/5.130008 (Ma Gnus v0.8) Emacs/24.3 (gnu/linux) Cancel-Lock: sha1:1e8KLsFTQEjWewGKdoxFGjRWiI4= X-Spam-Score: 1.3 (+) X-Spam-Report: SpamAssassin (3.3.1 2010-03-16) analysis follows Bayesian score: 0.0000 Ham tokens: 0.000-2388--15440h-0s--0d--H*u:Emacs, 0.000-72--464h-0s--0d--H*u:Gnus, 0.000-72--464h-0s--0d--H*UA:Gnus, 0.000-71--456h-0s--0d--H*u:linux, 0.000-71--456h-0s--0d--H*UA:linux Spam tokens: 0.991-13941--760h-68603s--0d--HTo:D*gnus.org, 0.991-14459--803h-71218s--0d--HX-Spam-Relays-External:quimby.gnus.org, 0.991-14459--803h-71218s--0d--H*RU:quimby.gnus.org, 0.988-14264--998h-71220s--0d--HX-Spam-Relays-Internal:quimby.gnus.org, 0.988-14264--998h-71220s--0d--H*RT:80.91.231.51 Autolearn status: no -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no trust [80.91.229.3 listed in list.dnswl.org] 1.2 RCVD_NUMERIC_HELO Received: contains an IP address used for HELO -0.0 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] 2.0 FSL_HELO_BARE_IP_2 FSL_HELO_BARE_IP_2 List-ID: Precedence: bulk Xref: news.gmane.org gmane.emacs.gnus.general:83937 Archived-At: Alexander Baier writes: > On 13-11-26 05:06 Eric Abrahamsen wrote: >> Frank Terbeck writes: >> >>> Eric Abrahamsen wrote: >>> [...] >>>> It also comes with its own tagging structure and all kinds of stuff I >>>> don't use. The superfluity bugs me a little, but the searching is nice >>>> enough that it doesn't matter. A nnir plugin for notmuch might actually >>>> be nice. >>> >>> Actually, at least in the git version of gnus, ‘nnir’ seems to feature >>> support for ‘notmuch’ (ie. there is a defcustom ‘nnir-notmuch-program’ >>> and a defun ‘nnir-run-notmuch’). >>> >>> Since ‘mu’ seems to work fairly similarly to notmuch, I would guess >>> that, this part would serve as a source for ideas for ‘mu’-integration. >>> >>> Regards, Frank >> >> Thanks to both of you for pointing that out! I had no idea that was >> there, but would definitely prefer using a more gnus-y interface. I set >> it up like so: >> >> (setq nnir-method-default-engines '((nnimap . notmuch) (nntp . gmane))) >> >> And gave it a shot. >> >> It didn't work for me for two reasons. I have several different imap >> servers, all run through dovecot with a maildir structure. They're all >> under ~/.mail, like ~/.mail/acc1 ~/mail/acc2 etc. That means >> nnir-notmuch-remove-prefix has to be set to an appropriate value for >> each server, which you can do with server parameters. But that means you >> can only search one server at a time (which I guess you'd do by putting >> a notmuch-group key into the query? I don't even know how to do that). >> That isn't really what I want -- I'd like to search all my mail at once. >> And even if I had to do it server by server, it seems like >> `nnir-run-notmuch' should be able to figure out how to filter to that >> server by itself... [...] > Hi Eric, > > I am digging this up again, as I had some time to look at this myself > and maybe have an idea of how to tackle this problem. > > Now, as I see it, the thing preventing us from searching multiple > servers is the fact that nnir-compose-result might be passed a server > that does not fit to the matched article as this may come from a > different server. So I think, solving this problem is "just" a matter > of teaching nnir-compose-result to correct the server it is passed in > case it does not fit to the matched article. For nnir-compose-result to > be able to so we need to tell it how to extract the server from the > dirnam parameter. The question is, how do we tell nnir-compose-result > this? Do you have any ideas on this? Right now, servers to search are chosen with `gnus-group-make-nnir-group', which does one of three things: 1. Extracts the server from the group under point 2. Extracts server from the marked groups, if groups are marked 3. If we're in the *Server* buffer, use the server under point Options one and three obviously only provide a single server, option two results in something like this (I marked the INBOXs of three different accounts): (("nnimap:acc1" ("nnimap+acc1:INBOX")) ("nnimap:acc2" ("nnimap+acc2:INBOX")) ("nnimap:acc3" ("nnimap+acc3:INBOX"))) What eventually happens is that `nnir-run-query' loops over each server in the above sexp (ignoring the group), and calls `nnir-run-notmuch' once for each server. Each loop passes the same search results to `nnir-compose-results', which filters the results based on the current server. So theoretically if you'd marked one group from each of the accounts you wanted to search, you'd get full results. We should be able to do the same thing by wrapping `gnus-group-make-nnir-group' and force-feeding it arguments: (setq notmuch-servers-to-search '(("nnimap:acc1") ("nnimap:acc2") ("nnimap:acc3"))) (defun nnir-search-all-servers (&optional query-spec) (interactive) (setq query-spec (or query-spec (list (cons 'query (read-string "Query: " nil 'nnir-search-history))))) (gnus-group-make-nnir-group nil (list (cons 'nnir-query-spec query-spec) (cons 'nnir-group-spec notmuch-servers-to-search)))) Can you set notmuch-servers-to-search appropriately, and test that? It's hard for me to test as I'm still having the "is it maildir or isn't it" problem, as well as the "I don't have an INBOX" problem. Thanks, Eric