Re: [RFC] Gnus generalized search, part II

[Andrew Cohen <cohen@bu.edu>]

>>>>> "Eric" == Eric Abrahamsen <eric@ericabrahamsen.net> writes:

    Eric> Eric Abrahamsen <eric@ericabrahamsen.net> writes: [...]

    >> If this only ever gets called from the summary buffer (possibly
    >> an incorrect assumption), would it make sense to pass the value
    >> of gnus-newsgroup-threads to `gnus-search-refer-thread' instead
    >> of bare message ids? gnus-newsgroup-threads already has the
    >> reference headers in it, and would get us halfway there
    >> already...

    Eric> Of course I realized right afterwards that this or something
    Eric> like it is exactly what you were talking about doing. I'm
    Eric> getting there, just slowly...


:)

The other reason for not using the search-engine based notion of
threading: my threads are often spread out over multiple servers (and
even multiple backend types, like imap and gmane). With nnselect gnus
has no problem making threads that span these things, and previously
with the old nnir and the current nnselect thread referral will 
work happily in this context (that is, gnus will create the thread with
all the articles that have been retrieved even crossing server and
backend types; then thread referral will attempt to consult ALL relevant
servers and backends to find as many thread related articles as
possible). Using the native thread searching won't be able to do this
well.

I do think the option should be available to do a native thread search,
but I strongly think the default should be the more general version that
we have now. It isn't particularly slow (and I doubt its significantly,
if at all, slower than native thread searching---it just lets gnus
construct the proper list of message ids rather than using a native
list).

I prefer passing the list of message-ids to gnus-search (rather than a
gnus construct like the dependencies hash), and then letting gnus-search
create the proper query and do the search (this is more or less how
things are now: nnselect calls nnimap-make-thread-query with the set of
message-ids to construct the query and then subsequently calls
nnir-run-query to do the search. We could keep the two steps or combine
into one function).  Aside from being simple and clean this has the
advantage of allowing the function to be called for any user-generated
(rather than gnus-generated) list of message-ids, not just a real
thread. That way you could use this function to make an nnselect group
of a bunch of related messages that weren't necessarily part of a
singlet thread. For example we have several threads related to this new
stuff going on in gmane.emacs.gnus.general and emacs-devel (and as soon
as I get around to posting my survey gmane.emacs.gnus.user :)) and this
would allow all of these things to appear as one group.

Best,
Andy