problem with notmuch search in recent emacs snapshots

problem with notmuch search in recent emacs snapshots

[Eric S Fraga]

Hello,

recently, I upgraded my emacs to the latest snapshot (20181111) on
Debian.  Since then, search in gnus does not work.  It always fails.  An
example of the messages that are generated follows:

--8<---------------cut here---------------start------------->8---
Doing notmuch query XXX on mail.misc mail.gemini mail.t3610 mail.pinto...
notmuch args: search --format=text --output=files XXX( path:mail.misc or path:mail.gemini or path:mail.t3610 or path:mail.pinto)
Massaging notmuch output...done
Search produced empty results.
gnus-select-newsgroup: Couldn’t request group nnir:nnir-87lg5rindf.fsf: Search produced empty results.
--8<---------------cut here---------------end--------------->8---

With the exact same gnus and notmuch configuration, everything is fine
with emacs snapshots from a couple of months ago; one of my systems is
running snapshot 20180909.  There is one obvious difference: the notmuch
arguments, for the same search, at the same topic, looks like this:

notmuch args: search --format=text --output=files XXX

I.e. no paths are specified.

I wonder whether the problem is the strange lack of a space between XXX
(my search term) and the opening "(" for the list of paths to check?
Even if only a single group is checked, the latest versions of gnus
append an explicit path.

If I turn nnir-notmuch-filter-group-names-function to nil, I get the old
behaviour back so I can still search but the default does not appear to
work.

Adding a space before "(" on line 1547 of nnir.el might fix this?
Untested.

thanks,
eric
-- 
Eric S Fraga via Emacs 27.0.50 & org 9.1.14 on Debian buster/sid

Re: problem with notmuch search in recent emacs snapshots

[Eric Abrahamsen]

Eric S Fraga <e.fraga@ucl.ac.uk> writes:

> Hello,
>

[...]

> Adding a space before "(" on line 1547 of nnir.el might fix this?
> Untested.

Yes! Sorry -- I added the parentheses in afterwards, and the space
that's currently in front of " path:%s" should have been moved before
the parenthesis. I'm surprised the other tester didn't run into this.
Would you be willing to move the space and give it a test?

Thanks,
Eric

Re: problem with notmuch search in recent emacs snapshots

[Eric S Fraga]

On Saturday, 17 Nov 2018 at 10:44, Eric Abrahamsen wrote:
> Eric S Fraga <e.fraga@ucl.ac.uk> writes:
>
>> Hello,
>>
>
> [...]
>
>> Adding a space before "(" on line 1547 of nnir.el might fix this?
>> Untested.
>
> Yes! Sorry -- I added the parentheses in afterwards, and the space
> that's currently in front of " path:%s" should have been moved before
> the parenthesis. I'm surprised the other tester didn't run into this.
> Would you be willing to move the space and give it a test?

I've tested but no luck.  There's more to this than the ()s.

Maybe I have not set something correctly but notmuch seems to expect
search terms like "path:mail/misc" and not "path:mail.misc".  I'm using
nnml.  Maybe maildir works differently; not sure what you have tested
this on.

Thanks,
eric

-- 
Eric S Fraga via Emacs 27.0.50 & org 9.1.14 on Debian buster/sid

Re: problem with notmuch search in recent emacs snapshots

[Eric Abrahamsen]

Eric S Fraga <e.fraga@ucl.ac.uk> writes:

> On Saturday, 17 Nov 2018 at 10:44, Eric Abrahamsen wrote:
>> Eric S Fraga <e.fraga@ucl.ac.uk> writes:
>>
>>> Hello,
>>>
>>
>> [...]
>>
>>> Adding a space before "(" on line 1547 of nnir.el might fix this?
>>> Untested.
>>
>> Yes! Sorry -- I added the parentheses in afterwards, and the space
>> that's currently in front of " path:%s" should have been moved before
>> the parenthesis. I'm surprised the other tester didn't run into this.
>> Would you be willing to move the space and give it a test?
>
> I've tested but no luck.  There's more to this than the ()s.
>
> Maybe I have not set something correctly but notmuch seems to expect
> search terms like "path:mail/misc" and not "path:mail.misc".  I'm using
> nnml.  Maybe maildir works differently; not sure what you have tested
> this on.

Yeah, maybe I should have left this off by default. You can get the
correct result by adding a filter function to
`nnir-notmuch-filter-group-names-function' -- the docstring of that
variable shows how to do it.

But all this requires users to know in advance that things have changed,
and to be willing to figure out how to adjust for their setup, and
that's not quite reasonable.

I think what I'll do is hard-code the `gnus-group-short-name' filter
into the body of the function (using fully qualified names will never be
correct), then default `nnir-notmuch-filter-group-names-function' to
nil, so behavior goes back to what it was, and then let user who are
willing to look into the issue set their own filters.

Sorry about that,
Eric

Re: problem with notmuch search in recent emacs snapshots

[Eric S Fraga]

On Sunday, 18 Nov 2018 at 10:59, Eric Abrahamsen wrote:
> I think what I'll do is hard-code the `gnus-group-short-name' filter
> into the body of the function (using fully qualified names will never be
> correct), then default `nnir-notmuch-filter-group-names-function' to
> nil, so behavior goes back to what it was, and then let user who are
> willing to look into the issue set their own filters.

Yes, I think having the default be the behaviour we had before would be
a good thing.  Thanks.

If I get a chance, I'll play around with the filtering to see if I can
get nnml groups working selectively.
-- 
Eric S Fraga via Emacs 27.0.50 & org 9.1.14 on Debian buster/sid

Re: problem with notmuch search in recent emacs snapshots

[Eric Abrahamsen]

Eric S Fraga <e.fraga@ucl.ac.uk> writes:

> On Sunday, 18 Nov 2018 at 10:59, Eric Abrahamsen wrote:
>> I think what I'll do is hard-code the `gnus-group-short-name' filter
>> into the body of the function (using fully qualified names will never be
>> correct), then default `nnir-notmuch-filter-group-names-function' to
>> nil, so behavior goes back to what it was, and then let user who are
>> willing to look into the issue set their own filters.
>
> Yes, I think having the default be the behaviour we had before would be
> a good thing.  Thanks.

Okay, I pushed that fix.