Re: nnir notmuch backend and the string-match function

[Alexander Baier <lexi.baier@gmail.com>]

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