bug#47130: 28.0.50; Gnus: mairix doesn't work anymore

[Eric Abrahamsen]

On 03/17/21 23:39 PM, Michael Heerdegen wrote:
> Eric Abrahamsen <eric@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