This could probably be used at quite a few places in the existing code,
but in the immediate future I plan to use in some new code in
notmuch-dump
---
notmuch-client.h | 5 +
status.c | 17 +
2 files changed, 22 insertions(+)
diff --git a/notmuch-client.h b/notmuch-cl
This lacks at least documentation. Note that it changes the default dump
output format, but doesn't break existing notmuch-restore. It might
break user scripts though.
---
notmuch-client.h | 6 ++
notmuch-dump.c | 41 ++---
notmuch-new.c
This is a thin wrapper around the Xapian metadata API. The job of this
layer is to keep the config key value pairs from colliding with other
metadata by transparently prefixing the keys, along with the usual glue
to provide a C interface.
The split of _get_config into two functions is to allow ret
Since xapian provides the ability to restrict the iterator to a given
prefix, we expose this ability to the user. Otherwise we mimic the other
iterator interfances in notmuch (e.g. tags.c).
---
lib/config.cc | 104 +
lib/notmuch.h |
Based on feedback on IRC from Austin and Tomi, I've simplified the API
and no longer expose the database level prefix to the caller.
This series does fix at least one memory ownership bug. Not a
particularly subtle one, I apparently only got half way through making
the current 'value' owned by the
On Tue, Jan 12, 2016 at 03:03:15PM -0400, David Bremner wrote:
> Nothing to do with Konrad's crash, but I consider the fact that the
> python bindings read ~/.notmuch-config to be a kind of layering
> violation, since that file belongs to the CLI, while the bindings
> are supposed to provide access
David Bremner writes:
>> No path means path=None, which stands for the path from
>> ~/.notmuch-config. That's exactly what I want. Is there some reason not
>> to rely on this mechanism?
>
> Oh sorry, I'm (obviously) not that familiar with the python bindings.
Nothing to do with Konrad's crash, b
On Tue, Jan 12, 2016 at 03:23:46PM +0100, Konrad Hinsen wrote:
> Hi Justus,
>
> > So I guess what happens is that Python3 changed how the
> > interpreter environment is torn down and they actually destroy the
> > 'q' object. If that is so, then your data is indeed safe.
>
> That reminds me of a
On Tue, Jan 12, 2016 at 10:41:57AM +0100, Konrad Hinsen wrote:
> --
> from notmuch import Query, Database
>
> def foo(bar):
> pass
>
> db = Database()
> q = Query(db, "*")
> db.close()
> --
>
> R
--- Begin Message ---
Package: notmuch-emacs
Version: 0.21-3
Severity: normal
When sending encrypted mail the key lookup to encrypt to is done case
sensitive on the mail address. As mail addresses are case insensitive
this should be done case insensitive. Otherwise keys for users which for
some re
Konrad Hinsen writes:
> David Bremner writes:
>
>>> from notmuch import Query, Database
>>>
>>> def foo(bar):
>>> pass
>>>
>>> db = Database()
>>> q = Query(db, "*")
>>> db.close()
>>
>> Do you really call the constructor without a path? Or are you censoring
>> the script for some reason?
>
Hi Justus,
> So I guess what happens is that Python3 changed how the interpreter
> environment is torn down and they actually destroy the 'q' object. If
> that is so, then your data is indeed safe.
That reminds me of a recent change in object finalization in Python 3:
https://www.python.org/d
David Bremner writes:
>> from notmuch import Query, Database
>>
>> def foo(bar):
>> pass
>>
>> db = Database()
>> q = Query(db, "*")
>> db.close()
>
> Do you really call the constructor without a path? Or are you censoring
> the script for some reason?
No path means path=None, which stands
Konrad Hinsen writes:
> Hi everyone,
>
> I have been writing quite a few Python scripts for notmuch before
> running into a strange bug. Here is a minimal script producing it:
>
> --
> from notmuch import Query, Database
>
> def foo(bar):
> pa
Hi everyone,
I have been writing quite a few Python scripts for notmuch before
running into a strange bug. Here is a minimal script producing it:
--
from notmuch import Query, Database
def foo(bar):
pass
db = Database()
q = Query(db, "*")
d
Hi everyone,
while looking for the latest source for checking if my recent bug report
still applies, I noticed that the README for the Python bindings is
hopelessly outdated. It refers to a bitbucket repository that hasn't
been updated since 2010. Moreover, it recommends installing from PyPI,
16 matches
Mail list logo