Re: searching local mail stores

[Eric Abrahamsen <eric@ericabrahamsen.net>]

Alan Schmitt <alan.schmitt@polytechnique.org> writes:

> Hello,
>
> (Sorry if you are seeing this as a duplicate. I tried to post it
> through the gmane group but I'm not seeing it, so here it is again
> directly to the mailing list.)
>
> On 2016-01-03 17:04, Eric Abrahamsen <eric@ericabrahamsen.net> writes:
>
>>>> In .gnus I have added:
>>>>
>>>>   (nnir-search-engine notmuch)
>>>>
>>>> in my mail-method ((nnml "")).
>>>>
>>>> I search by going to my email-topic and pressing GG.
>>>
>>> What else needs to be setup to use notmuch for search?
>>>
>>> (There's some info on setup here for instance:
>>> http://roland.entierement.nu/blog/2010/09/08/gnus-dovecot-offlineimap-search-a-howto.html
>>> )
>>>
>>> Is that the sort of setup that needs doing first?
>>
>> This, but also ‘nnir-notmuch-remove-prefix’. Notmuch knows nothing about
>> Gnus, it just knows where matching files are on your filesystem. Gnus
>> only wants to know the filename relative to where it *already knows how
>> to find the message*. You customize that option in order to match the
>> two up. The option is basically copied from nnir-namazu-remove-prefix,
>> which has a more useful docstring...
>
> I'm giving this a try, and I'm having a problem: whatever I try, I get
> an error:
>
> gnus-select-newsgroup: Couldn't request group nnir:nnir-m2bn91ihar.fsf:
> Search produced empty results.
>
> If I run the notmuch command on the command line, I see many results.
> I tried to run edebug on the nnir-run-notmuch function, and it does
> something strange. It actually populates a temporary buffer with the
> results I see when running the command line, but then it seems to go
> through these results discarding all of them.
>
> #+begin_src emacs-lisp
> (while (not (eobp))
>   (setq filenam (buffer-substring-no-properties (line-beginning-position)
>                                                 (line-end-position))
>         artno (file-name-nondirectory filenam)
>         dirnam (file-name-directory filenam))
>   (forward-line 1)
>
>   ;; don't match directories
>   (when (string-match article-pattern artno)
>     (when (not (null dirnam))
>
>     ;; maybe limit results to matching groups.
>       (when (or (not groupspec)
>             (string-match groupspec dirnam))
>         (nnir-add-result dirnam artno "" prefix server artlist)))))
> #+end_src
>
> The problem is in the matching of the name of the file (something like
> "1451911994.M307856P59885.charm-ecran.irisa.fr,S=3270,W=3347:2,S")
> against the pattern "^[0-9]+$", which fails and the found message is
> ignored.
>
> Is this a bug in this function, or do I need additional configuration?
>
> Here are my server settings:
>
> (setq gnus-select-method 
>       '(nnimap 
>         "zimbra"
>         (nnimap-shell-program
>          "~/bin/dovecot_bin/imap -c ~/.dovecotzimbra.rc")
>         (nnimap-stream shell)
>         (nnimap-logout-timeout 1.0)
>         (nnir-search-engine notmuch)
>         (nnir-notmuch-remove-prefix "/Users/schmitta/.Maildir/zimbra/")))
>
> (setq gnus-secondary-select-methods 
>       '((nnimap 
>          "local"
>          (nnimap-address "localhost")
>          (nnimap-server-port 143)
>          (nnimap-stream network)
>          (nnir-search-engine notmuch)
>          (nnir-notmuch-remove-prefix "/Users/schmitta/.Maildir/local"))
>         ))
>

I think the problem is that you can't actually use notmuch with the
nnimap backend. Earlier in that function, you see that the
"article-pattern" regexp is different depending on whether you're using
an nnmaildir backend or not. In fact, if it uses the regexp associated
with nnmaildir, it looks like your articles would probably match, and
come out in the results.

I don't really understand the reasoning behind this -- I suppose you
could alter the function to always use the other regexp, and see if
anything else breaks.

But I think the idea is: if you're using an IMAP server, you're supposed
to be letting the server do the searching, and give you the results.
Searching the filesystem directly is kind of "going behind the server's
back". I don't actually know if that would cause any real problems, but
the code is definitely set up with that assumption in mind.

Maybe try the FTS dovecot plugin?

Eric