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

[jao]

On Thu, Dec 30 2021, Eric Abrahamsen wrote:


[...]

> Okay, here goes the next try. A few things to note:
>
> - I realized notmuch already has a "thread:{<sub-query>}" syntax that
>   does the double search I was doing in elisp, so now we just use that 
> instead.

makes sense.

> - In all my testing I couldn't see that having "duplicate=1" on thread
>   searches causes any problems, so I've taken it off. Can you please
>   doublecheck this? If it's still mucking it up for you, I'll put it
>   back in. I wish I really understood what the problem is (I think it
>   has to do with notmuch potentially storing the same message in
>   multiple locations, using symlinks).

hmm, are you sure you've removed it? i can see, after applying your
diff, at least for files searches:

    (cl-defmethod gnus-search-indexed-search-command ((engine 
gnus-search-notmuch)
                                                  (qstring string)
                                                  query &optional _groups)
      ;; Theoretically we could use the GROUPS parameter to pass a
      ;; --folder switch to notmuch, but I'm not confident of getting the
      ;; format right.
      (let ((limit (alist-get 'limit query)))
        (with-slots (switches config-file) engine
          (append
           (list (format "--config=%s" config-file)
                 "search"
                 "--output=files"
                 "--duplicate=1")
           (when limit (list (format "--limit=%d" limit)))
           switches
           (list qstring)))))

at any rate, i had already tried searches without it in my patched
version and haven't seen any adverse effects.  my understanding is that
notmuch is clever enough to detect duplicate messages with different
filenames .


> - The search result filtration now won't filter on group names if the
>   search is a thread search. This should resolve the issue you were
>   seeing where "A T" would only search within the group you had searched
>   in to begin with. I guess I think that an explicit thread search by
>   the user should result in a full scan of the server. We can see if
>   that surprises/annoys anyone, though.

the behaviour for me is the same as with my previous patch: A T stays in
the nnselect group.  a thing to notice is that, in general, there is no
single "the group you had searched in to begin width" (pretty often, i
do searches accross all my nnml groups, of which i have plenty)... a
full scan of the server is, i think, precisely what a notmuch user would
expect :) (but i don't know if this is really supposed to work for
gnus-search: in general, collecting all messages of a thread will return
messages from a list of different gnus groups: should we be able to show
all of them in an ephemeral group then?).

be it as it may, even with the full original thread belonging to a
single nnml group, A T is leaving me in nnselect with only the messages
that were already there (i.e., it's not equivalent to A W followed by A
T... but then again, maybe it's not supposed to be?)

thanks a lot!
jao
-- 
Beauty is the purgation of superfluities.
  -Michelangelo Buonarroti (1475-1564)