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>
Before the change, the last loop in guess_from_received_header()
did not reset domain and tld variables to NULL. This leads to
double free error in some cases and possibly other bugs.
Before the change, headers and message visibility functions took
extra care to correctly set `buffer-invisibility-spec'. This was
needed because headers overlay `invisible' property had only
headers' invisibility spec. So visibility of headers was
determined only by the headers invisibility spec. The patch sets
headers overlay `invisible' property a list with both the headers
and the message invisibility spec. This makes headers invisible
if either of them is added to the `buffer-invisibility-spec' and
allows to simplify the code.
Before the patch, message, headers and hidden citation overlays
had zero priority. All these overlay have `invisible' property.
Emacs documentation says that we should not make assumptions
about which overlay will prevail when they have the same priority
[1]. It happens to work as we need, but we should not rely on
undocumented behavior.
[1] http://www.gnu.org/s/emacs/manual/html_node/elisp/Overlay-Properties.html
Before the change, message and citation invisibility overlays
conflicted: if some citation is made visible and then the whole
message is hidden, that citation remained visible. This happened
because the citation's overlay has an invisible property which
takes priority over the message overlay. The message
invisibility spec does not affect citation visibility, it is
determined solely by the citation overlay invisibility spec.
Hence, if citation is made visible, it is not hidden by message
invisibility spec.
The patch changes citation overlay invisibility property to be a
list which contains both the citation and the message
invisibility specs. This makes the citation invisible if either
of them is added to the `buffer-invisibility-spec'. Note that
all citation visibility states are "restored" when the message
hidden and shown again.
Before the change, the `notmuch-show-insert-text/plain-hook' was
given only the `depth' argument. The patch adds another one -
the message. Currently, the new message argument is not used by
any on the hooks. But it will be used later to get access to
message invisibility specs when wash buttons are inserted.
The emacs bug is that isearch cannot search through invisible text
when the 'invisible' property is a list.
The patch adds `notmuch-isearch-range-invisible' function which
is the same as `isearch-range-invisible' but with fixed Emacs bug
#8721. Advice added for `isearch-range-invisible' which calls
`notmuch-isearch-range-invisible' instead of the original
`isearch-range-invisible' when in `notmuch-show-mode'.
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>
The intent was always to make these Received headers span multiple
lines. But the escapes were causing the shell to ignore the newlines,
so that the result instead was long Received headers on a single line
each.
Fixing the intent here doesn't actually change the test-suite results
at all.
We're not properly concatenating the Received headers if we parse them
while requesting a header that isn't Received.
this fixes notmuch-reply address detection in a bunch of situations.
This is much more realistic, as most messages in the wild will have multiple
Received headers. Also, this demonstrates a current bug in the Received
header parsing, (multiple Received headers are not properly concatenated
depending on the order in which headers are parsed in a message).
This tests the recently-added detection/hiding of top-posted quotations and
in the testing, it takes advantage of the less-recently-added
visible-buffer-string function for emitting only the visible text
from a buffer.
This code treats top posted copies essentially like signatures, except
that it doesn't sanity check their length, since neither do their
senders.
New user-visible variables:
notmuch-wash-button-original-hidden-format
notmuch-wash-button-original-visible-format
Rebased-by: Carl Worth <cworth@cworth.org>
Our use of GMimeSession was unneeded boilerplate, and we weren't doing
anything with it. This simplifies and clarifies that assumption.
If we want to do anything fancier later, the examples in the gmime
source are a reasonable source to work from in defining a new
GMimeSession derivative.
Since GMimeSession is going away in GMime 2.6, though, i don't
recommend using it.
GMime has a nasty habit of taking ownership by default of any FILE*
handed to it va g_mime_stream_file_new. Specifically it will close the
FILE* when the stream is destroyed---even though GMime didn't open the
file itself.
To avoid this bad behavior, we have to carefully set_owner(FALSE)
after calling g_mime_stream_file_new. In the format_part_content_text
function, since commit d92146d3a6 we've
been calling g_mime_stream_file_new unconditionally, but only calling
g_mime_stream_file_set_owner(FALSE) conditionally.
This led to the FILE* being closed early when notmuch show output was
redirected to a file.
Fixing this fixes the test-suite cases that broke with the previous
commit, (which added redirected "notmuch show" calls to the test suite
to expose this bug).
Edited-by: Carl Worth <cworth@cworth.org> with a new commit message to
explain the bug and fix.
Again, this is a much cleaner and more thorough test, and in fact
exposes a bug in the format=text output, that will be fixed the next
commit. Because of this, some of the multipart tests currently fail.
This is a much cleaner way to do the emacs tests, since we're actually
comparing output against existing files with expected output. We also
won't miss any trailing newlines this way.
And speaking of which, one of the expected output files was actually
missing a trailing blank line that was actually in one of the original
messages, so this was fixed.
Mail-header-parse-address may fail for an invalid address.
Before the change, this would result in empty notmuch-show buffer
with an error message like: Scan error: "Unbalanced parentheses".
The patch wraps the function in condition-case and returns
unchanged address in case of error.
Most of the time, every entry in the list of identities has the same user name
part. It can then be filled in automatically, and the user can only be prompted
for the email address, which makes the interface much cleaner.
For message-fetch-field the buffer is expected to be narrowed to
just the header of the message. That is not the case when
notmuch-fcc-header-setup is run, hence a wrong header value may be
returned. E.g. when forwarding an
email, (message-fetch-field "From") returns the From header value
of the forwarded email.
Message-field-value is the same as message-fetch-field, only
narrows the buffer to the headers first.
Signed-off-by: Jameson Graef Rollins <jrollins@finestructure.net>
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>
(describe-face 'message-cited-text-face)
> message-cited-text-face is an alias for the face `message-cited-text'.
> This face is obsolete since 22.1; use `message-cited-text' instead.
Signed-off-by: Pieter Praet <pieter@praet.org>
Signed-off-by: Jameson Graef Rollins <jrollins@finestructure.net>
This feature was recently added, so it of course needs a test now.
Signed-off-by: Jameson Graef Rollins <jrollins@finestructure.net>
Edited-by: Carl Worth <cworth@cworth.org> Fixed test to use
notmuch_search_sanitize in order to be robust against unpredictable
thread ID numbers, (due to unpredictable order in which the filesystem
presents files).
When a Subject field contained encoded CRLF sequences, these sequences
would appear unfiltered in the output of notmuch search. This confused
the notmuch emacs interface leading to "Unexpected Output"
messages. This is now fixed by replacing all characters with ASCII
code less than 32 with a question mark.
Signed-off-by: Jameson Graef Rollins <jrollins@finestructure.net>
Signed-off-by: Jameson Graef Rollins <jrollins@finestructure.net>
jrollins modified this patch to conform to recent changes in the
crypto processing since this patch was originally sent in.
In the master branch in test/emacs two tests access the build users home
directory, so does emacs_deliver_message in the crypto branch.
The tests should not touch the build user's home directory. The patch
creates a directory in the temporary test directory and sets home
accordingly.
In case of a non-existent home directory, the tests are failing without
this patch.
Signed-off-by: Jameson Graef Rollins <jrollins@finestructure.net>
This test doesn't have anything to do with json, and has everything to
do with testing search capability, so I'm not sure why it was in the
wrong place.
The "Search for non-existent message prints nothing" test fits better
with the existing tests in search-output, so move it there. Also add a
similar test for the --format=json case.
These tests also use the new test_expect_equal_file function, (to ensure
that the presence of a trailing newline is correctly tested).
A previous commit to fix json formatting for null results
(0b1ddc5f66) accidentally introduced a
regression that removed trailing newlines for non-json output. (There
wasn't a good test for this previously, but there is now). The
problem is due to the fundamental differences in formatting between
the json and non-json outputs. The only way to fix this was to add a
new formatting field that represents the string to output at the end
of a null result.
All output formatting tests should pass now, (in particular, the 4
recent test failures introduced to show this bug).
These test now properly test for the presence of a newline at the end
of all output. Right now some of these test will fail because the
search output is currently broken to *not* produce proper newlines in
some cases.
