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.
Ever since commit b4b5e9ce4d the
detection of libdir in the ldconfig configuration has been broken,
resulting in RPATH being set when not needed and not wanted.
The cause was a change from an IFS setting of:
IFS="$(printf '\n\t')"
to a new setting of:
IFS="$(printf '\n')"
That looks desirable since we want to split the output of ldconfig
based on newlines, (and not split on any filename that might have an
embedded tab in it). The subtle bug in the above is that the shell
trims any trailing newlines when performing command substitution so
the final statement above was equivalent to:
IFS=''
which prevented any splitting of the ldconfig output at all.
Fix this by avoiding command substitution and just using a literal
newline in the source file for setting this variable.
Now that this function registers an internal error if called with a
non-text part, we can remove the conditions for multipart and
message-part content types.
This fixes the recently-added test case (in test/multipart)
demonstrating corruption of binary parts that happen to contain CRLF
pairs.
We restore the original code from show_one_part_content to
format_part_content_raw. Then, for good measure, we rename
show_part_content to the more descriptive show_text_part_content and
add an internal error if it is ever called with a non-text part.
Since commit 2f8871df6e notmuch has been
using a function (show_part_content) originally written only for text
parts to save all MIME parts. The problem with this is that this
function converts CRLF pairs to LF only and optionally converts to
UTF-8 encoding. These two conversions have the potential to corrupt
binary data when passed through the function.
This test demonstrates that corruption, and so fails currently, until
we fix the bug.
Not that it affects the correctness of the test, but it's nice to use
proper spelling. This kind of change could invalidate a signature on the
test message, but I think that would have happened previously when the
HTML part was added in the first place.
Use .gz filenames for saved attachments in the tests to check
that Emacs does not re-compress the file.
Use test_expect_equal_file instead of test_expect_equal to avoid
binary output on the console.
Before the change, test_expect_equal_file moved files it compared
in case of failure. The patch changes it to copy the files
instead. This allows testing non-temporary files which are
stored in git.
Note: the change should not result in new temporary files left
after the tests. Test_expect_equal_file used to move files only
on failure, so callers had to cleanup them anyway.
Write-region handles some file names specially, see Emacs Lisp
manual section 25.11 Making Certain File Names "Magic" [1]. This
is a nice feature for normal text editing, but it is not
desirable if we need to save raw file content (e.g. attachment).
In particular, this affects archives and may result in corrupted
attachments saved with notmuch-show-save-part (attachment button
click handler).
Turns out, smart GNUS folks encountered the same problem and
implemented write-region wrapper which inhibits some file name
handlers. In particular, this wrapper is used in mm-save-part,
which is why notmuch-save-attachments that uses it works fine
with archives.
The patch replaces write-region with mm-write-region in
notmuch-show-save-part. Also it removes coding-system-for-write
and require-final-newline setting in notmuch-show-save-part. The
former is set in mm-write-region. The latter seems to be
unneeded because mm-save-part does not use it.
[1] http://www.gnu.org/s/emacs/manual/html_node/elisp/Magic-File-Names.html
This is the best way to make the displayed output for
decrypted/verified messages clearer. The special sigstatus and
encstatus buttons are now displayed under the part header button. The
part header button is also tweaked to provide information to user
about how to proces crypto.
We probably shouldn't have been doing this anyway, but we do it here
specifically because we don't want the content of the
application/pgp-encrypted parts to be displayed and cluttering the
message show.
The primary goal here is to keep the decrypted output as similarly
structured as undecrypted output as possible. Now, when decrypting
parts, only the original encrypted part is replaced by the it's
decrypted content. If this part isn't itself a multipart, then all
part numbering should remain consistent during decryption.
The only draw back here is that the useless application/pgp-encrypted
sub-part of the multipart/encrypted part is also emitted. But this
part can be easily ignored by clients.
Some folks have complained about the part renumbering that occurs when
the entire multipart/signed part is replaced with the part contents
after verification. This is primarily because it incurs an additional
computational cost to retrieve individual parts, since verification
has to be performed again to ensure that part numbering is consistent.
This patch simply leaves the full multipart/signed part as is.
The emacs crypto test is also updated to reflect this change.
This patch adds the tag "signed" to messages with any multipart/signed
parts, and the tag "encrypted" to messages with any
multipart/encrypted parts. This only occurs when messages are indexed
during notmuch new, so a database rebuild is required to have old
messages tagged.
A new emacs configuration variable "notmuch-crypto-process-mime"
controls the processing of PGP/MIME signatures and encrypted parts.
When this is set true, notmuch-query will use the notmuch show
--decrypt flag to decrypt encrypted messages and/or calculate the
sigstatus of signed messages. If sigstatus is available, notmuch-show
will place a specially color-coded header at the begining of the
signed message.
Also included is the ability to switch decryption/verification on/off
on the fly, which is bound to M-RET in notmuch-search-mode.
This adds support for decrypting PGP/MIME-encrypted parts to
notmuch-show and notmuch-reply. The --decrypt option implies
--verify. Once decryption (and possibly signature verification) is
done, a new part_encstatus formatter is emitted, the part_sigstatus
formatter is emitted, and the entire multipart/encrypted part is
replaced by the contents of the encrypted part.
At the moment only a json part_encstatus formatting function is
available, even though decryption is done for all formats. Emacs
support to follow.
This is primarily for notmuch-show, although the functionality is
added to show-message. Once signatures are processed a new
part_sigstatus formatter is emitted, and the entire multipart/signed
part is replaced with the contents of the signed part.
At the moment only a json part_sigstatus formatting function is
available. Emacs support to follow.
The original work for this patch was done by
Daniel Kahn Gillmor <dkg@fifthhorseman.net>
whose help with this functionality I greatly appreciate.
This adds a new "crypto" test script to the test suite to test
PGP/MIME signature verification and message decryption. Included here
is a test GNUPGHOME with a test secret key (passwordless), and test
for:
* signing/verification
* signing/verification with full owner trust
* verification with signer key unavailable
* encryption/decryption
* decryption failure with missing key
* encryption/decryption + signing/verfifying
* reply to encrypted message
* verification of signature from revoked key
These tests are not expected to pass now, but will as crypto
functionality is included.
We need to be able to test for the presence of a newline at the end of
output. There's no good way to capture trailing newlines in bash, so
redirecting output to a file is the next best thing. This new
function should be used when testing for output that is expected to
have trailing newlines.
The next commit will demonstrate the use of this.
Future improvements (eg. crypto support) will require adding new part
header. By breaking up the output of part headers from the output of
part content, we can easily out new part headers with new formatting
functions.
After the last patch to eliminate some redundant code paths in
reply_part, the reply_part_content function was only being called
once. Disolving the function and integrating its contents into the
reply_part function makes things a little simpler, and frees up some
name space that will be needed in the next patch.
The patch replaces all (message (buffer-string)) calls in emacs
tests with (princ (buffer-string)). This avoids accidentally
interpreting '%' as format specifiers and makes code simpler
because we do not need to capture stderr.
Also, the patch works around an Emacs (23.3+1-1 on current Debian
Unstable) segfault in "Ensure that emacs doesn't drop results"
test. Note: the segfault does not happen on every test run.
Though, it seems to be consistently reproducible if the test uses
300 messages instead of 30. Hopefully, it is the crash described
in Emacs bug #8545 [1] which is already fixed.
[1] http://debbugs.gnu.org/cgi/bugreport.cgi?bug=8545
