From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/79541 Path: news.gmane.org!not-for-mail From: Andrew Cohen Newsgroups: gmane.emacs.gnus.general Subject: Re: `gnus-refer-article-methods' and `gnus-summary-refer-thread' Date: Sat, 23 Jul 2011 12:02:29 -0400 Message-ID: <87fwlxoui2.fsf@andy.bu.edu> References: <87r55honjt.fsf@andy.bu.edu> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: dough.gmane.org 1311436992 26732 80.91.229.12 (23 Jul 2011 16:03:12 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sat, 23 Jul 2011 16:03:12 +0000 (UTC) To: ding@gnus.org Original-X-From: ding-owner+M27837@lists.math.uh.edu Sat Jul 23 18:03:06 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 1QkefQ-00026D-LK for ding-account@gmane.org; Sat, 23 Jul 2011 18:03:04 +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 1Qkef8-0006YN-0O; Sat, 23 Jul 2011 11:02:46 -0500 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 1Qkef6-0006Y8-GL for ding@lists.math.uh.edu; Sat, 23 Jul 2011 11:02:44 -0500 Original-Received: from quimby.gnus.org ([80.91.231.51]) by mx1.math.uh.edu with esmtps (TLSv1:AES256-SHA:256) (Exim 4.76) (envelope-from ) id 1Qkef4-0001mn-N8 for ding@lists.math.uh.edu; Sat, 23 Jul 2011 11:02:44 -0500 Original-Received: from lo.gmane.org ([80.91.229.12]) by quimby.gnus.org with esmtp (Exim 4.72) (envelope-from ) id 1Qkef3-0003Hu-AL for ding@gnus.org; Sat, 23 Jul 2011 18:02:41 +0200 Original-Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1Qkef3-0001xb-02 for ding@gnus.org; Sat, 23 Jul 2011 18:02:41 +0200 Original-Received: from andy.bu.edu ([128.197.41.152]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 23 Jul 2011 18:02:40 +0200 Original-Received: from cohen by andy.bu.edu with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 23 Jul 2011 18:02:40 +0200 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 86 Original-X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: andy.bu.edu User-Agent: Gnus/5.110018 (No Gnus v0.18) Emacs/24.0.50 (gnu/linux) Cancel-Lock: sha1:LGI55twd2PWqhpvL0+mWa/TFXkA= X-Spam-Score: -6.1 (------) List-ID: Precedence: bulk Xref: news.gmane.org gmane.emacs.gnus.general:79541 Archived-At: >>>>> "Dave" == Dave Abrahams writes: Dave> on Fri Jul 22 2011, Andrew Cohen wrote: >>>>>>> "Dave" == Dave Abrahams writes: >> Dave> It's a bit curious that when I'm sitting on the root of a Dave> thread, `A T' doesn't find the rest of it via nnir when I have Dave> that in `gnus-refer-article-methods'. >> >> `A T' (gnus-summary-refer-thread) doesn't use >> gnus-refer-article-methods at all. This is distinct from `^` >> (gnus-summary-refer-parent-article) which consults the entries in >> `gnus-refer-article-methods' in order until the parent is found. Dave> Right. Like I said in the part of my post you didn't cite, I Dave> think I understand why it's that way, but it seems like a Dave> programming artifact rather than a design decision. Finding the parent is finding a single article with a given Message-ID. Once found we know to stop. Since gnus has no idea how many articles are in a thread it doesn't know when it should stop. So looping through a set of methods doesn't make much sense to me. Instead, we just try a single method, which is the search I described. Aside from broken mailers, this will find the whole thread within the given group. I'm still not entirely clear, but I think your only unhappiness is the restriction to searching within the group rather than across all groups on the server. Is this right? >> For nnimap groups `A T' searches /in the current group/ for any >> article that is referenced in the primary article, or refers to >> the primary article or any of its references. In rare cases where >> mailers have not properly coordinated references it is possible >> for this to miss articles, but it should be rare and avoiding it >> would require recursing searches which would be very slow. [...] >> What it does /not/ do is search across multiple groups, and this >> is the most likely reason for not finding all articles within a >> thread. Dave> Yes, I'm aware that's why it's not finding the article. OK, if this is the only case that's at issue, the change I am about to check in should do what you want. >> The current function adds the found articles from the current >> group into the summary buffer. Nnir creates an ephemeral group >> which can contain articles from multiple groups which is >> substantively different. Dave> Yes, but when I use `^' it can use nnir to insert articles Dave> that don't exist in the current group into the current group's Dave> summary buffer... which would is substantively similar to what Dave> I'm asking for ;-) The problem is that when inserting an article header from a foreign group into an existing summary buffer, gnus has no way to keep track of where that article came from. It assigns it a phony (negative) article number so it knows its not native, but thats it. So every time you try to do something with it (like read it), it has to perform the search again. This isn't too bad for one or two foreign articles (provided the search is fast, which it usually is for retrieving a single article with a known message-id), but is horrible if you have a thread with many articles in it. Nnir does two things, really: it performs queries to find articles according to search criteria; and it creates ephemeral groups based on these query results. Searching for messages with a given Message-ID, or for messages within the current group, only use the first capability. >> Having said that I am just about to check in a modification that >> will allow searching across multiple groups through the use of a >> prefix-arg or setting a variable. Rather than calling the current >> `gnus-summary-refer-thread' this will construct the same imap >> search pattern but use nnir to search across the entire server >> and create an ephemeral group with the results. Dave> I'm not yet sure I understand what you're describing. I think I'm doing what you are asking for: the ability to return a group containing all the articles in a thread, even if these articles are spread across multiple groups. If I don't have this right, let me know.