[BUG] notmuch-search: notmuch search process already running for query
Dear All, I just have started using notmuch with Emacs. When I run `notmuch-poll-and-refresh-this-buffer` which run script '.notmuch/hooks/pre-new': #!/bin/sh mbsync -L gmail Most of the time it gives me an error & message: "notmuch-search: notmuch search process already running for query ‘tag:inbox’". But sometimes it works properly and I can download new emails. So I have to run it a few times to update my emails. It's pretty annoying. How to fix that? notmuch --version: notmuch 0.38.2+20~g52a5446 emacs-version: GNU Emacs 29.1.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.24, cairo version 1.16.0) of 2023-07-30 Regards, Sławomir ___ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-le...@notmuchmail.org
Re: BUG: Python's Message.header fails for empty headers
Am Di., 9. Jan. 2024 um 13:38 Uhr schrieb David Bremner : > > Michael J Gruber writes: > > >> > >> I agree the bindings documentation does not make much sense. I suspect > >> that the bindings should follow the underlying library and return "" if > >> the library does. I don't use the bindings that much, so I am curious > >> what others think. > > > > I might be misunderstanding the OP,and I didn't check the RFC, but > > isn't there a difference between a missing header and an empty header? > > Are you suggesting the library should change as well? I don't know. Missing vs. empty are two different cases. It may be that in terms of e-mail standards (RFC), a missing header is equivalent to an empty one. Then one can argue whether an empty header is a missing header (raise error) or a missing header is an empty header (return None) ... Or one may distinguish between mandatory headers and optional ones. I'd really check the RFC. In Python, there is a difference between a dictionary key with an empty value and a key which is not present, of course. So, if I think of the headers as a dictionary, I would expect to differentiate between those cases, unless the data which the dict represents (e-mail headers) treats them as equal by RFC. > > If there is, this may come down to the difference between testing for > > an empty string, None or False in dynamically typed python ... > > But it does make sense for the bindings to return an empty string or > > None for an empty header and LookUpError for a missing header. I have > > not checked whether our bindings in fact do. > > > > AFAICT it checks explicitely for NULL, but then throws LookupError on > any falsy return from capi.ffi.string > > ret = capi.lib.notmuch_message_get_header(self._msg_p, name) > if ret == capi.ffi.NULL: > raise errors.NullPointerError() > hdr = capi.ffi.string(ret) > if not hdr: > raise LookupError > return hdr.decode(encoding='utf-8') That clarifies what OP observed :) ___ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-le...@notmuchmail.org
Re: BUG: Python's Message.header fails for empty headers
Michael J Gruber writes: >> >> I agree the bindings documentation does not make much sense. I suspect >> that the bindings should follow the underlying library and return "" if >> the library does. I don't use the bindings that much, so I am curious >> what others think. > > I might be misunderstanding the OP,and I didn't check the RFC, but > isn't there a difference between a missing header and an empty header? Are you suggesting the library should change as well? > If there is, this may come down to the difference between testing for > an empty string, None or False in dynamically typed python ... > But it does make sense for the bindings to return an empty string or > None for an empty header and LookUpError for a missing header. I have > not checked whether our bindings in fact do. > AFAICT it checks explicitely for NULL, but then throws LookupError on any falsy return from capi.ffi.string ret = capi.lib.notmuch_message_get_header(self._msg_p, name) if ret == capi.ffi.NULL: raise errors.NullPointerError() hdr = capi.ffi.string(ret) if not hdr: raise LookupError return hdr.decode(encoding='utf-8') ___ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-le...@notmuchmail.org
Re: BUG: Python's Message.header fails for empty headers
Am Di., 9. Jan. 2024 um 00:09 Uhr schrieb David Bremner : > > Vojtěch Káně writes: > > > At first, this sounds reasonable: the subject is empty, so it is > > effectively missing. That would indicate a bug in Lieer itself and would > > be fixed by a try-catch block. Notmuch's source for Message.header, > > however, states: > > > >>:returns: The header value, an empty string if the header is not present. > >>:rtype: str > > > > This makes an impression that no error should be raised and a harmless > > value (at least for the above-mentioned code) should be returned. Yet > > the docs continue with > > > >>:raises LookupError: if the header is not present. > > > > completely contradicting itself. > > > > And so here the questions: > > Is my confusion justified? What is the expected nm's behavior? Can we > > fix the docs and possible the implementation? > > > > I agree the bindings documentation does not make much sense. I suspect > that the bindings should follow the underlying library and return "" if > the library does. I don't use the bindings that much, so I am curious > what others think. I might be misunderstanding the OP,and I didn't check the RFC, but isn't there a difference between a missing header and an empty header? If there is, this may come down to the difference between testing for an empty string, None or False in dynamically typed python ... But it does make sense for the bindings to return an empty string or None for an empty header and LookUpError for a missing header. I have not checked whether our bindings in fact do. Also, note that *sending* via lieer (i.e. via GMail API) provides more pitfalls. For example, message IDs are rewritten, which makes it unusable for patch series. Cheers, Michael ___ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-le...@notmuchmail.org
