From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/80043 Path: news.gmane.org!not-for-mail From: Dave Abrahams Newsgroups: gmane.emacs.gnus.general Subject: Re: nnir, gnus-goto-article and such Date: Mon, 26 Sep 2011 16:46:51 -0400 Message-ID: References: <87mxdwd944.fsf@andy.bu.edu> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: dough.gmane.org 1317070030 20927 80.91.229.12 (26 Sep 2011 20:47:10 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Mon, 26 Sep 2011 20:47:10 +0000 (UTC) Cc: ding@gnus.org To: Andrew Cohen Original-X-From: ding-owner+M28337@lists.math.uh.edu Mon Sep 26 22:47:05 2011 Return-path: Envelope-to: ding-account@gmane.org Original-Received: from util0.math.uh.edu ([129.7.128.18]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1R8I4v-0001QN-5o for ding-account@gmane.org; Mon, 26 Sep 2011 22:47:05 +0200 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 1R8I4t-000573-GJ; Mon, 26 Sep 2011 15:47:03 -0500 Original-Received: from mx2.math.uh.edu ([129.7.128.33]) by util0.math.uh.edu with esmtps (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from ) id 1R8I4s-00056s-7a for ding@lists.math.uh.edu; Mon, 26 Sep 2011 15:47:02 -0500 Original-Received: from quimby.gnus.org ([80.91.231.51]) by mx2.math.uh.edu with esmtps (TLSv1:AES256-SHA:256) (Exim 4.76) (envelope-from ) id 1R8I4q-0003h0-Rd for ding@lists.math.uh.edu; Mon, 26 Sep 2011 15:47:02 -0500 Original-Received: from mail-vw0-f44.google.com ([209.85.212.44]) by quimby.gnus.org with esmtp (Exim 4.72) (envelope-from ) id 1R8I4p-0007I9-5p for ding@gnus.org; Mon, 26 Sep 2011 22:46:59 +0200 Original-Received: by vws5 with SMTP id 5so8489101vws.17 for ; Mon, 26 Sep 2011 13:46:53 -0700 (PDT) Original-Received: by 10.52.65.165 with SMTP id y5mr6558699vds.397.1317070013050; Mon, 26 Sep 2011 13:46:53 -0700 (PDT) Original-Received: from pluto.luannocracy.com (207-172-223-249.c3-0.smr-ubr3.sbo-smr.ma.static.cable.rcn.com. [207.172.223.249]) by mx.google.com with ESMTPS id x19sm18359343vdf.10.2011.09.26.13.46.51 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 26 Sep 2011 13:46:52 -0700 (PDT) Original-Received: by pluto.luannocracy.com (Postfix, from userid 501) id 3D6C4FDDEC8; Mon, 26 Sep 2011 16:46:51 -0400 (EDT) In-Reply-To: <87mxdwd944.fsf@andy.bu.edu> (Andrew Cohen's message of "Thu, 22 Sep 2011 09:01:15 -0400") User-Agent: Gnus/5.110018 (No Gnus v0.18) Emacs/23.3 (darwin) X-Spam-Score: -2.9 (--) List-ID: Precedence: bulk Xref: news.gmane.org gmane.emacs.gnus.general:80043 Archived-At: on Thu Sep 22 2011, Andrew Cohen wrote: >>>>>> "John" == John Wiegley writes: > > [...] > > John> What doesn't work is that 'A T' doesn't do everything it can > John> to recursively find all referenced articles from all > John> refer-article sources. > > The logic used in 'A T' is different from that of 'A R' and friends > because its doing something different. That's not to say that it doesn't > have bugs, and I'm sure that it can be improved. Andrew, I think there's a miscommunication here. John is talking about what he sees as a design/operational deficiency, while you're talking about the implementation. For example, `A T' starts out with a call to `gnus-warp-to-article'. However, `gnus-warp-to-article' for some reason only works in nnir groups. There are several other backends that aggregate messages from other groups, but none of them remembers where the messages came from. Even if I happen to have the article in the registry, and *it* knows which group it came from, I won't end up warping there. And I think that's the cause of a lot of the grief John and I are experiencing. > John> In contrast, if you hand-select each article that 'A R' finds, > John> and then press 'A R' on that, and so on recursively, you will > John> ultimately end up with the entire thread. > > I don't think this gives the entire thread. It only gives the articles > that precede the article you start with along the current branch. ...and does `A T' always do *at least* that well? It should, IMO. > If > there are subsequent articles along the current branch, or articles on > another branch, this recursive procedure won't find them. That's why the > 'A T' function tries to do a /search/ for articles rather than just > recursive retrieval. This is complicated by the limitations of the > different kinds of servers. Right... you know, I could swear that wanderlust lets me search in nntp groups. It has a single uniform interface to these searches across all backends. *looks it up* yeah, it's called a filter folder. I wonder how that works? Aha, it looks like maybe they use the server for everything but body searches (which we don't care about for thread-following)? I'm not entirely sure. --8<---------------cut here---------------start------------->8--- (defun elmo-nntp-use-server-search-p (condition) (if (vectorp condition) (not (string= "body" (elmo-filter-key condition))) (and (elmo-nntp-use-server-search-p (nth 1 condition)) (elmo-nntp-use-server-search-p (nth 2 condition))))) --8<---------------cut here---------------end--------------->8--- > Here is the complete `A T' logic for nntp and nnimap groups: > > 1. nntp: The nntp protocol has no searching capabilities at all, so > there is no way to search by message-id. Gmane has a Xapian-powered > search engine written by Olly Betts that works very well, but doesn't > allow searching by message-id. If it does full-text searches you could narrow the field by searching for the message-id anyway. > What gnus does in this case is very primitive: it retrieves the > headers for a (configurable) number of articles before and after the > current article (250 before and 250 after by default) in the current > group, and then gnus itself searches within these headers for articles > belonging to the thread. But there is no way to know if there are > other articles in the thread in other groups or on other servers. > > 2. nnimap: The imap protocol allows searching by headers, but only > within a single group. So by default if you `A T' on an article in an > nnimap group a search will be performed for all the articles that > might be in the thread in the current group only. > > Recently I added the ability to replace this search with an nnir > search which will look for articles in the thread on the whole server > rather than just in the current group. But it won't look outside the > server. Right... we'd like it to use all the resources that could be at its disposal; that is, everything in gnus-refer-article-method. > I have also recently re-written much of nnir, but I won't push it > until after the freeze is over. As part of this re-write, when > searching for a thread on the whole server the registry is consulted > to see what group the article on which you invoke `A T' came from, > and consult /both/ that server and the server containing the current > group. This is a very minor improvement, since most of the time these > two servers will be the same. Except in my case, where I'm creating an ephemeral group to hold the referenced article. I think that's exactly what I want right now. > I guess we can consult the registry for all the articles mentioned in > the references header and see if any of those articles came from > different servers and search those servers as well. But if they are nntp > servers we can't really search them effectively (since nntp doesn't have > search facilities). Wow; we can't pull up a message by ID from NNTP? too bad. > We could also configure this to /always/ search a particular set of > servers independently of where the proximate article came from. IMO, use `gnus-refer-article-method'; it already answers the question :-) -- Dave Abrahams BoostPro Computing http://www.boostpro.com