According to the common Ruby function naming convention, potentially
dangerous functions or functions which operate on the object itself are
suffixed with an exclamation mark. Both of these are true for object
destroying functions.
The following modules are affected:
- Notmuch::Directory
- Notmuch::FileNames
- Notmuch::Query
- Notmuch::Threads
- Notmuch::Thread
- Notmuch::Messages
- Notmuch::Message
- Notmuch::Tags
If we use unicode objects, libnotmuch would not cope with null bytes in
the byte array, so we need to make sure they are nicely formatted as
utf-8.
Introduce a helper function _str which does this throughout the code.
Patch slightly modified by Sebastian Spaeth.
Signed-off-by: Sebastian Spaeth <Sebastian@SSpaeth.de>
we now have three files to keep in sync. That seems wrong, but I guess
we will live with it for now.
The main problem is that the python code is distributed separately, so
it can't get the version from 'version'.
The choice ~rcX is for convenience with debian versioning.
Decode and Encode from/to unicode objects as required to be able to take
unicode path names. Previously we would error out when an unicode object
were handed it.
Signed-off-by: Sebastian Spaeth <Sebastian@SSpaeth.de>
Importing the notmuch module in setup.py is a no-no, and we want
to auto-generate the version number in the release process.
Outsource __VERSION__ to the new version.py which contains nothing else
and which can therefor easily be autogenerated. Have setup.py read in
the file via execfile and test if importing the version number actually
worked.
This should make all happy.
Signed-off-by: Sebastian Spaeth <Sebastian@SSpaeth.de>
This reverts commit 8826fc2d7b.
It seems that importing the module in setup.py is controversial at best,
as it will fail for users that don't have all dependencies
installed. This was the case in e.g. the Ubuntu autobuilder, so building
notmuch failed. The plan is to create an autogenerated setup.py that can
be used for version information.
Signed-off-by: Sebastian Spaeth <Sebastian@SSpaeth.de>
We were using a template setup.py which parsed __init__.py in complex
ways just to find out the version number. Simply import notmuch and use
__VERSION__ directly. Also adapt some wording and setup.py values while
going through.
Signed-off-by: Sebastian Spaeth <Sebastian@SSpaeth.de>
This prevents unsafe calls to decode for return value None in
get_authors/get_subject which would current throw an Exception. Original
patch modified by Sebastian Spaeth.
Signed-off-by: Sebastian Spaeth <Sebastian@SSpaeth.de>
len() exhausts the tag iterator and e.g. list() or "".join(tags)
implicitly call len() if existing and then failing. So, we remove
Tags.__len__().
If you need to know the number of tags a message has, do use
len(list(tags)). It would be nicer to be able to support len() directly...
Signed-off-by: Sebastian Spaeth <Sebastian@SSpaeth.de>
If we try to pull a non-existing tag, Tags._get will return None and the
appended .decode() command will fail. So make sure that there is a tag to
be fetched before fetching it.
Signed-off-by: Sebastian Spaeth <Sebastian@SSpaeth.de>
In case, search_threads returns an error we are supposed to throw an
Exception. But we did not "raise" it, this was an oversight and this
commit fixes it.
There is still the problem that there is often output to stderr by
libnotmuch detailing the xapian error and this is simply printed
out. But this requires fixing at the libnotmuch level...
Signed-off-by: Sebastian Spaeth <Sebastian@SSpaeth.de>
Rather than returning simply strings and having to guess their encoding,
return explicit unicode() strings for the tags. Xapian stores UTF8, so
we know that they come as UTF8 encoded string.
Note: I tried to directly use the c_wchar_p type of the ctypes library
which translates directly into an unicode type, but that did not work
out so well, so we take c_char_p and .decode() them manually.
Signed-off-by: Sebastian Spaeth <Sebastian@SSpaeth.de>
If we pass in an unicode instance as query string, we would probably get
weird behavior (and indeed do so, see mail
id:"20110707113700.GA16347@megatron"). If a unicode instance is passed
in, make sure we encode it properly to an utf-8 encoded byte string.
Signed-off-by: Sebastian Spaeth <Sebastian@SSpaeth.de>
A stupid typo was preventing this from ever working and it was not
detected until now. Patrick noted the typo and proposed the fix in mail
id:"20110704203926.GA20238@brick.lan".
Patch-by: Patrick Totzke <patricktotzke@googlemail.com>
Signed-off-by: Sebastian Spaeth <Sebastian@SSpaeth.de>
In order to remain consistent with the underlying C API, we do not
automatically synchronize notmuch tags and maildir flags anymore.
The underlying functions Message.maildir_flags_to_tags and
Message.tags_to_maildir_flags still exist and are available to the user.
Signed-off-by: Sebastian Spaeth <Sebastian@SSpaeth.de>
Importing notmuch loads the notmuch shared library. When building
without a system install of notmuch, this requires e.g. setting
LD_LIBRARY_PATH for building and fails completely for cleaning.
We were still using len(self.get_replies()) for the __str__ summary of a
mail, but 1) len(Messages()) has just gone away 2) the number of replies
can not be retrieved when we got the message via search_messages()
anyway, and 3) it is likely quite expensive to pull all replies for all
messages that we display a summary of.
So we fix this by simplifying str(Message()) to omit the number of replies.
Signed-off-by: Sebastian Spaeth <Sebastian@SSpaeth.de>
libnotmuch (and python) crashed when I accidently passed in an invalid
value as path argument to the Database() instantiation.
Therefore, we now check via assert that the handed in path is actually a
real string (or None).
Signed-off-by: Sebastian Spaeth <Sebastian@SSpaeth.de>
and also maildir_flags_to_tags. The methods will be invoked by
db.add_message() and also (if not overridden via function parameter) by
add|remove_tag and remove_all_tags. Documentation on the usage has been
updated.
Signed-off-by: Sebastian Spaeth <Sebastian@SSpaeth.de>
Improve the documentation with regard to the new __cmp__ and __hash__
methods and the implications of doing set arithmetic with Messages()
objects.
Signed-off-by: Sebastian Spaeth <Sebastian@SSpaeth.de>
We can now do: if msg1 == msg2, and we can use set arithmetic on
Messages():
s1, s2= msgs1, msgs2
s1.union(s2)
s2 -= s1
Signed-off-by: Sebastian Spaeth <Sebastian@SSpaeth.de>
Messages.__len__() exhausted the iterator and list() inherently calls
len(), so we could not invoke list(msgs) without getting errors. Fix
this by implementing __nonzero__ but removing __len__ on Messages.
Use Query.count_messages() or len(list(msgs)) if you need to know the
number.
Signed-off-by: Sebastian Spaeth <Sebastian@SSpaeth.de>
To match the upcoming release, and with the updated API to match the
current libnotmuch, bump the python version number (notmuch.__VERSION__)
to 0.6.
Signed-off-by: Sebastian Spaeth <Sebastian@SSpaeth.de>
Analog to Threads.__nonzero__ this allows us to perform list() on a Threads() object and to repeatedly call "if Tags():" or "bool(Tags())" without implicitly invoking len(), thus exhausting our iterator.
While touching this code, I added a small micro-optimization to the Tag next() function. There is no need to explicitly check _is_valid, as _get implicitly does check for validness and returns None, if there is no more Tag to fetch. This avoids some roundtrips into the library when iterating through Tags.
Signed-off-by: Sebastian Spaeth <Sebastian@SSpaeth.de>
__nonzero__ checks if Threads() contains at least one more valid thread
The existence of this function makes 'if Threads(): foo' work, as that
previously implicitely called len() exhausting the iterator. This
function makes `bool(Threads())` work repeatedly.
For further info, see http://docs.python.org/reference/datamodel.html.
Credits for the hint go to Brian May.
Signed-off-by: Sebastian Spaeth <Sebastian@SSpaeth.de>
They had accidentally been left out, so we should also include the
function docs for get_messages in the API docs.
Signed-off-by: Sebastian Spaeth <Sebastian@SSpaeth.de>
Message().get_filenames() will return a generator that allows to
iterator over the recorded filenames for a certain Message. Do ntoe that
as all generators, these are one-time use only. You will have to reget
them to perform various actions. So this works::
len(Message().get_filenames())
list(Message().get_filenames())
for n in Message().get_filenames():
print n
But this won't::
names = Message().get_filenames()
len(names) #uses up the iterator
list(names) #outch, already used up...
Signed-off-by: Sebastian Spaeth <Sebastian@SSpaeth.de>
The old instructions were telling users to do "easy_install cnotmuch"
which installed some old, stale bindings. The new instructions should
be much more effective.
