From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/79544 Path: news.gmane.org!not-for-mail From: Dave Abrahams Newsgroups: gmane.emacs.gnus.general Subject: Re: `gnus-refer-article-methods' and `gnus-summary-refer-thread' Date: Sat, 23 Jul 2011 13:16:00 -0400 Message-ID: References: <87r55honjt.fsf@andy.bu.edu> <87fwlxoui2.fsf@andy.bu.edu> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: dough.gmane.org 1311441399 17920 80.91.229.12 (23 Jul 2011 17:16:39 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sat, 23 Jul 2011 17:16:39 +0000 (UTC) To: ding@gnus.org Original-X-From: ding-owner+M27840@lists.math.uh.edu Sat Jul 23 19:16:35 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 1QkfoW-0004pb-Qf for ding-account@gmane.org; Sat, 23 Jul 2011 19:16:33 +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 1QkfoK-0006vm-HV; Sat, 23 Jul 2011 12:16:20 -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 1QkfoH-0006vQ-Hv for ding@lists.math.uh.edu; Sat, 23 Jul 2011 12:16:17 -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 1QkfoG-0001oB-8Z for ding@lists.math.uh.edu; Sat, 23 Jul 2011 12:16:17 -0500 Original-Received: from lo.gmane.org ([80.91.229.12]) by quimby.gnus.org with esmtp (Exim 4.72) (envelope-from ) id 1QkfoE-00054Z-Sb for ding@gnus.org; Sat, 23 Jul 2011 19:16:14 +0200 Original-Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1QkfoD-0004hN-PS for ding@gnus.org; Sat, 23 Jul 2011 19:16:13 +0200 Original-Received: from 207-172-223-249.c3-0.smr-ubr3.sbo-smr.ma.static.cable.rcn.com ([207.172.223.249]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 23 Jul 2011 19:16:13 +0200 Original-Received: from dave by 207-172-223-249.c3-0.smr-ubr3.sbo-smr.ma.static.cable.rcn.com with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 23 Jul 2011 19:16:13 +0200 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 99 Original-X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: 207-172-223-249.c3-0.smr-ubr3.sbo-smr.ma.static.cable.rcn.com User-Agent: Gnus/5.110018 (No Gnus v0.18) Emacs/23.3 (darwin) Cancel-Lock: sha1:PpfrxCJP/EoWBBDG90MRCDXp/Jc= X-Spam-Score: -6.1 (------) List-ID: Precedence: bulk Xref: news.gmane.org gmane.emacs.gnus.general:79544 Archived-At: on Sat Jul 23 2011, Andrew Cohen wrote: >>>>>> "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. Oh, but it's an easy single search: the root of the thread is the first message-ID in the `References' header. Then you look for anything whose `Message-ID' matches the root id or whose `References' contains the root id. [You could easily make it a bit more thorough in case of broken threads by making use of more of the contents of `References', but I've found this to work perfectly well in practice]. > 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? Well, as mentioned earlier, I'm only interested in looking in *one* other group on the server. But I'd also like to find messages in the registry and agent if possible (hey, why not ask for the moon, I figure?). > >> 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. Oh. I feel unclean. :-P > 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. Yuck, I see! > 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. I think you have this right. Although, let me add, if there's no way to limit which groups on a server are searched it's going to be way too slow for me (because I have too many groups). And thanks for all you're doing! -- Dave Abrahams BoostPro Computing http://www.boostpro.com