Re: gnus-search-engine set to gnus-search-notmuch and refer threads

[Eric Abrahamsen]

Andrew Cohen <acohen@ust.hk> writes:

>>>>>> "EA" == Eric Abrahamsen <eric@ericabrahamsen.net> writes:
>
>     EA> "Jose A. Ortega Ruiz" <jao@gnu.org> writes:
>
> [...]
>
>     EA>  - The search result filtration now won't filter on group names
>     EA> if the search is a thread search. This should resolve the issue
>     EA> you were seeing where "A T" would only search within the group
>     EA> you had searched in to begin with. I guess I think that an
>     EA> explicit thread search by the user should result in a full scan
>     EA> of the server. We can see if that surprises/annoys anyone,
>     EA> though.
>
> Umm, maybe I am misunderstanding this paragraph, but there is a variable
> for explicit control of this:
>
> (defcustom gnus-refer-thread-use-search nil
>   "Search an entire server when referring threads.
> A nil value will only search for thread-related articles in the
> current group."
>   :version "28.1"
>   :group 'gnus-thread
>   :type 'boolean)
>
> I usually expect a full server search but not always. Hence this
> variable. I hope that the methods will respect it so that the user can
> control the result. Of course if some method is incapable of doing both
> kinds of searches then there would be no choice.
>
> Now that I am sending this, perhaps the original bug resulted from the
> default nil value for this variable?

Ugh, that's what I get for not re-reading the whole thread every time I
sit down to work on something like this.

Yes, the problem (and the only problem) was that notmuch was
constructing its thread queries incorrectly, and I'm pretty sure that
problem is now fixed.

`gnus-refer-thread-use-search' should definitely be respected. Let me
think about this. If that variable is nil, search isn't used at all, in
which case no code in gnus-search.el matters. If it is t, then search is
used, but the "groups" parameter is set to nil, in which case the edit
in the previously-attached patch doesn't matter.

In fact the only thing the patch changes is how gnus-search behaves if
the user enters a search query including "thread:t". So it was my
message that was wrong.

And my last confusion was thinking that I wasn't seeing a conflict
between --thread and --duplicate=1, when in fact the attached patch
simply never uses --thread.

So, despite much dumbness, I think the patch is still correct.

WDYT?

Eric