Re: [RFC] Gnus generalized search, part II

[Eric Abrahamsen <eric@ericabrahamsen.net>]

Andrew Cohen <cohen@bu.edu> writes:

>>>>>> "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 wonder if we have a misunderstanding... My original assumption was
that native thread searching would only be responsible for locating the
relevant messages, *not* for creating thread structures. Ie, engines
supply lists of messages from their respective backends that they
believe to be relevant to the original list of message-ids. All those
messages get dumped in flat list into a summary buffer, and Gnus does
its usual thread construction routines. "notmuch --thread" and "mairix
--threads" return flat lists to begin with. IMAP THREAD returns nested
lists, but I'd been assuming that I would flatten those results out
before passing them to nnselect.

Each engine pretty much does the same trick of
references/in-reply-to/maybe-subject, but I have to believe they do a
more efficient job of it in their own domains. But then we let Gnus do
the final threading before presenting the results to the user.

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

I'm happy with this, I really don't have an opinion on where the
reference deconstruction should happen.

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

If my assumptions above are correct, then this is how it would work,
even with native thread searching.

Does that make sense?