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

[Andrew Cohen <cohen@andy.bu.edu>]

>>>>> "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. 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.