bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#47096: 28.0.50; gnus-search notmuch can't find files when using nnim


From: Eric Abrahamsen
Subject: bug#47096: 28.0.50; gnus-search notmuch can't find files when using nnimap
Date: Sat, 13 Mar 2021 15:02:10 -0800
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux)

Kevin Brubeck Unhammer <unhammer@fsfe.org> writes:

> If I have a gnus backend for a local dovecot instance like
>
>                           '(nnimap "mbsync"
>                                          (nnimap-address "localhost")
>                                          (gnus-search-engine notmuch
>                                                              (config-file 
> "/home/me/.notmuch-config")
>                                                              (remove-prefix 
> "/home/me/.Maildir/"))
>                                          (nnimap-shell-program 
> "MAIL=maildir:$HOME/.Maildir /usr/lib/dovecot/imap")
>                                          (nnimap-stream shell))
>
> then Gnus isn't able to translate the filenames returned from notmuch
> (e.g. inbox/cur/1615384505.697011_1.laptop,U=5667)
> into article numbers. It seems to look up using a function that assumes
> you're using nnmaildir:

Thanks for the report. Just to be clear, is this something that used to
work before gnus-search landed, and now doesn't? My understanding is
that this part of the code hasn't changed, and this wouldn't have ever
worked, but I'd very much like to know if that's not true.

Basically, there is an ugly bit of heuristics when looking at search
results, and guessing how to handle them. As you've noticed, if the file
name looks like a maildir message, the search code will assume there's
an nnmaildir server involved, and try to find it.

There should be a dedicated method in place to handle a single search
result, which is able to take both the server and the search engine into
account. I've been gnawing on what that might look like, but haven't
implemented it yet.

Eric





reply via email to

[Prev in Thread] Current Thread [Next in Thread]