Re: `gnus-refer-article-methods' and `gnus-summary-refer-thread'

[Dave Abrahams <dave@boostpro.com>]

on Sat Jul 23 2011, Andrew Cohen <cohen-AT-andy.bu.edu> wrote:

>>>>>> "Dave" == Dave Abrahams <dave@boostpro.com> writes:
>
>     Dave> on Fri Jul 22 2011, Andrew Cohen <cohen-AT-andy.bu.edu> wrote:
>     >>>>>>> "Dave" == Dave Abrahams <dave@boostpro.com> 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