GNU bug report logs -
#47130
28.0.50; Gnus: mairix doesn't work anymore
Previous Next
Full log
Message #47 received at 47130 <at> debbugs.gnu.org (full text, mbox):
On 03/17/21 23:39 PM, Michael Heerdegen wrote:
> Eric Abrahamsen <eric <at> ericabrahamsen.net> writes:
>
>> I was finally able to get mairix to index a test server, and searching
>> worked just fine. One thing I realized afterwards is that I had set the
>> remove-prefix to the directory where the actual mails are kept
>> ("/home/eric/Mail"), whereas it looks like you've set it to the
>> directory where mairix is supposed to put its search-result symlinks
>> ("/home/micha/mairix").
>
> Indeed: I changed that and now searching works well! Many thanks, dunno
> how long I would have had to continue debugging until I had found that.
You would have had to find your way to the definition of
`gnus-search-indexed-parse-output', implemented for the
`gnus-search-indexed' engine class. Mairix isn't mentioned anywhere
around there. Generic functions are awesome, but there can definitely be
a discoverability problem.
>> This is the main difference between nnmairix and gnus-search with
>> mairix: nnmairix actually creates new groups and reads them directly,
>> gnus-search returns a list of results that refer to messages on the
>> original server. The "-r" option is passed to mairix, which tells it not
>> to create its own folders but return the original file names of matched
>> results -- that's why remove-prefix has to refer to the underlying
>> server.
>>
>> Hope that makes sense.
>
> Makes a lot of sense, yes.
>
>> I suppose I should add a note to the documentation?
>
> Yes, it would be good to make that clearer.
I will add a note to the manual, and probably also some code comments at
the top of gnus-search.el, giving hints for bug-hunters. I can close
this bug report when that's done.
> BTW, I didn't even understand why it is even necessary to provide that.
> If Gnus gets absolute names from mairix, why isn't it able to resolve
> them in this case?
The local-indexed search code conflates the two issues of 1) where is
the file that represents a single search results, and 2) how do we get
from that file path to an article number that a Gnus server will
understand.
If you look at the code in the function mentioned above, you'll see the
whole process is surprisingly hacky. The "remove-prefix" is chopped off
the front of the filepath, then the next part of the filepath is
interpreted as a group name, then it attempts to turn the non-directory
filename into an article number somehow. If the remove-prefix is wrong,
the later code gets a full filepath and doesn't know what to do with it.
I think all nnmail-type servers have some config for "directory" or
"nnmh-directory" or whatever, and I think there's a good chance that the
remove-prefix can be made redundant with this config.
I'm a little surprised it works as well as it does!
Eric
This bug report was last modified 3 years and 155 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.