nnir notmuch backend and the string-match function

nnir notmuch backend and the string-match function

[Alexander Baier]

Hello,

I am currently trying to set up maildir search while using notmuch as a
nnir backend.  So far, however, this has not been very successful.

Issuing a search using "G G" on a nnmaildir group presents me with the
following error message:

"Unknown header type nil while requesting articles                     of
group nnmaildir+gmail:gmail.Inbox"

So I started digging around in nnir.el and came across a very strange
bug I can't explain.  In the function `nnir-compose-result' there is
the following expression:

#+begin_src emacs-lisp
  (when (string-match (concat "^" prefix) dirnam)
    (setq dirnam (replace-match "" t t dirnam)))
#+end_src

I stepped through this code with edebug and was very confused:
The value of dirnam is "/home/delexi/Mail/gmail/Inbox/cur/" and the value of
prefix is "/home/delexi/Mail/".  To my surprise `string-match' did not
match anything!  This of course leads to errors in the code following
this snippet.  I tried this snippet in my scratch buffer and everything
worked fine (it matched the prefix correctly).

How is this possible?  Is there something about string-match I am
missing?  How is it possible, that this does not match anything?

#+begin_src emacs-lisp
  (string-match "^/home/delexi/Mail/"
                "/home/delexi/Mail/gmail/Inbox/cur/")
#+end_src

Thanks in advance,
-- 
 Alexander Baier

Re: nnir notmuch backend and the string-match function

[Alexander Baier]

Hello again,

On 13-11-27 21:26 Alexander Baier wrote:
> Hello,
>
> I am currently trying to set up maildir search while using notmuch as a
> nnir backend.  So far, however, this has not been very successful.
>
> Issuing a search using "G G" on a nnmaildir group presents me with the
> following error message:
>
> "Unknown header type nil while requesting articles                     of
> group nnmaildir+gmail:gmail.Inbox"
>
> So I started digging around in nnir.el and came across a very strange
> bug I can't explain.  In the function `nnir-compose-result' there is
> the following expression:
>
> #+begin_src emacs-lisp
>   (when (string-match (concat "^" prefix) dirnam)
>     (setq dirnam (replace-match "" t t dirnam)))
> #+end_src
>
> I stepped through this code with edebug and was very confused:
> The value of dirnam is "/home/delexi/Mail/gmail/Inbox/cur/" and the value of
> prefix is "/home/delexi/Mail/".  To my surprise `string-match' did not
> match anything!  This of course leads to errors in the code following
> this snippet.  I tried this snippet in my scratch buffer and everything
> worked fine (it matched the prefix correctly).
>
> How is this possible?  Is there something about string-match I am
> missing?  How is it possible, that this does not match anything?
>
> #+begin_src emacs-lisp
>   (string-match "^/home/delexi/Mail/"
>                 "/home/delexi/Mail/gmail/Inbox/cur/")
> #+end_src
>
> Thanks in advance,

I tested this a bit more and found out that edebug apparently alters
match-data in some way which in turn alters the programs execution
depending on whether I am currently debugging or not.

#+begin_src emacs-lisp
  (when (string-match (concat "^" prefix) dirnam)
    (message "%s" (match-data)) ;; this was added
    (setq dirnam (replace-match "" t t dirnam)))
#+end_src

Executing the code with the modified piece above and without edebug
prints the right match-data.  So this explains the weird matching
behavior.  Is this a bug in edebug, or is this some unavoidable
restriction?

Regards,
-- 
 Alexander Baier

Re: nnir notmuch backend and the string-match function

[Lars Ingebrigtsen]

Alexander Baier <lexi.baier@gmail.com> writes:

> Executing the code with the modified piece above and without edebug
> prints the right match-data.  So this explains the weird matching
> behavior.  Is this a bug in edebug, or is this some unavoidable
> restriction?

It sounds like a bug in edebug.  I haven't seen edebug doing anything
like that -- it seems to work fine for me with stuff like that.

-- 
(domestic pets only, the antidote for overdose, milk.)
  bloggy blog http://lars.ingebrigtsen.no/

Re: nnir notmuch backend and the string-match function

[Alexander Baier]

On 2013-12-26 17:23 Lars Ingebrigtsen wrote:
> Alexander Baier <lexi.baier@gmail.com> writes:
>
>> Executing the code with the modified piece above and without edebug
>> prints the right match-data.  So this explains the weird matching
>> behavior.  Is this a bug in edebug, or is this some unavoidable
>> restriction?
>
> It sounds like a bug in edebug.  I haven't seen edebug doing anything
> like that -- it seems to work fine for me with stuff like that.

I am still using Emacs 24.3, do you use the current trunk by any chance?
I might have been fixed there.

Regards,
-- 
 Alexander Baier

Re: nnir notmuch backend and the string-match function

[Lars Ingebrigtsen]

Alexander Baier <lexi.baier@gmail.com> writes:

> I am still using Emacs 24.3, do you use the current trunk by any chance?
> I might have been fixed there.

Yeah, I use the current trunk.

-- 
(domestic pets only, the antidote for overdose, milk.)
  bloggy blog http://lars.ingebrigtsen.no/