In X, Emacs distinguishes the tab key, which produces a 'tab event;
from C-i, which produces a ?\t event. However, in a terminal, these
are indistinguishable and only produce a ?\t event. In order to
simplify things, Emacs automatically translates from 'tab to ?\t (see
"Function key translations" in M-x describe-bindings), so functions
only need to be bound to ?\t to work in all situations.
Previously, the search tab completion code usedq (kbd "<tab>"), which
produced the event sequence [tab], which only matched the 'tab event
and hence only worked in X. This patch changes it to (kbd "TAB"),
which matches the general ?\t event and works in all situations.
When the exclude tags contain a tag that does not occur anywhere in
the Xapian database the exclusion fails. We modify the way the query
is constructed to `work around' this. (In fact the new code is cleaner
anyway.)
It also seems to fix another exclusion failure bug reported by
jrollins but we have not yet worked out why it helps in that case.
This adds three tests for --output=messages searches. One test is for
the case when one exclude tag does not occur in the Xapian
database. This triggers a Xapian bug in some cases and causes the
whole exclusion to fail. The next commit avoids this bug.
The tests for the exclude code in search and count use the line
notmuch config set search.exclude_tags = deleted
which actually sets the exclude tags to be "=" and "deleted". Remove
the "=" from this line.
Allow query debugging to be enabled at run-time by setting the
NOTMUCH_DEBUG_QUERY environment variable to a non-empty string.
Previously, enabling query debugging required recompiling, but parsed
queries are often useful for tracking down bugs in situations where
recompiling is inconvenient.
Before the change, messages generated by generate_message() used "Test
message #N" for default subject where N is the generated messages
counter. Since message subject is commonly present in expected
results, there is a chance of breaking other tests when a new
generate_message() call is added. The patch changes default subject
value for generated messages to subtest name if it is available. If
subtest name is not available (i.e. message is generated during test
initialization), the old default value is used (in this case it is
fine to have the counter in the subject).
Another benefit of this change is a sane default value for subject in
generated messages, which would allow to simplify code like:
test_begin_subtest "test for a cool feature"
add_message [subject]="message for test for a cool feature"
Before the change, the first subtest in raw format tests just
generated messages and checked that they are added successfully. This
is not really a raw format test, it is creating of environment
required for other subtests to run. The patch removes the first
subtest from raw and replaces it with bare add_message calls, similar
to how it is done in other tests.
TODO: we should check that test environment was created successfully.
Currently, many tests do add_message(), notmuch new and other calls
without checking the results. We should come up with a general
solution for this, i.e. if any command during test initialization
fails, all tests should be skipped with appropriate error message.
This is fully compatible for root and leaf parts, but now has proper
support for interior parts. This requires some design decisions that
were guided by what I would want if I were to save a part.
Specifically:
- Leaf parts are printed without headers and with transfer decoding.
This is what makes sense for saving attachments. (Furthermore, the
transfer decoding is necessary since, without the headers, the
caller would not be able to interpret non-transfer-decoded output.)
- Message parts are printed with their message headers, but without
enclosing part headers. This is what makes sense for saving a
message as a whole (which is a message part) and for saving attached
messages. This is symmetric for whole messages and for attached
messages, though we special-case the whole message for performance
reasons (and corner-case correctness reasons: given malformed input,
GMime may not be able to reproduce it from the parsed
representation).
- Multipart parts are printed with their headers and all child parts.
It's not clear what the best thing to do for multipart is, but this
was the most natural to implement and can be justified because such
parts can't be interpreted without their headers.
As an added benefit, we can move the special-case code for part 0 into
the raw formatter.
Formatter errors are propagated to the exit status of notmuch show.
This isn't used by the JSON or text formatters, but it will be useful
for the raw format, which is pickier.
Previously, there was only one CRLF between the terminating boundary
of the embedded multipart/alternative and the boundary of the
containing multipart. However, according the RFC 1341, 7.2.1:
The boundary must be followed immediately either by another CRLF and
the header fields for the next part, or by two CRLFs, in which case
there are no header fields for the next part
and
The CRLF preceding the encapsulation line is considered part of the
boundary so that it is possible to have a part that does not end
with a CRLF (line break).
Thus, there must be *two* CRLFs between these boundaries: one that
ends the terminating boundary and one that begins the enclosing
boundary.
While GMime accepted the message we had before, it could not produce
such a message.
Formerly it was possible for *message_ret to be left
uninitialized. The documentation however clearly states that "[o]n any
failure or when the message is not found, this function initializes
'*message' to NULL".
Signed-off-by: Justus Winter <4winter@informatik.uni-hamburg.de>
gmime-2.6 had a bug [1] which made it impossible to tell why a signature
verification failed when the signer key was unavailable (empty "sigstatus" field
in the JSON output). Since 00b5623d the corresponding test is marked as broken
when using gmime-2.6 (2.4 is fine).
This bug has been fixed in gmime 2.6.5, which is now the minimal gmime-2.6
version required for building notmuch (gmime-2.4 is still available). As a
consequence the version check in test/crypto can be removed.
[Added by db]
Although less unambigously a bug, Gmime 2.6 prior to 2.6.7 also was
more strict about parsing, and rejected messages with initial "From "
headers. This restriction is relaxed in [2]. For reasons explained in [3],
we want to keep this more relaxed parsing for now.
[1] https://bugzilla.gnome.org/show_bug.cgi?id=668085
[2] http://git.gnome.org/browse/gmime/commit/?id=d311f576baf750476e06e9a1367a2dc1793ea7eb
[3] id:"1331385931-1610-1-git-send-email-david@tethera.net"
Previously, the configure script would appear to detect gmime-2.6 if
present. However, the binaries would end up being compiled against
gmime-2.4. The addition of a break fixes things so that now gmime-2.6
will be used if available, falling back to gmime-2.4.
The reply MML quoting added in commit ae438cc unintentionally MML
quotes also the signature/encryption MML tags added via
message-setup-hook, causing the reply not to be signed/encrypted.
MML quote just the original message in the temp buffer before
inserting it to the message buffer, to not interfere with message mode
hooks or message construction in general.
See [1] and [2] for bug reports.
Thanks to Tim Bielawa <tbielawa@redhat.com> for testing.
[1] id:"87hay78x6l.fsf@wyzanski.jamesvasile.com"
[2] id:"1330812262-28272-1-git-send-email-tbielawa@redhat.com".
Signed-off-by: Jani Nikula <jani@nikula.org>
This reverts
dfee0f9 man: remove search.exclude_tags from notmuch-config.1 for 0.12
e83409d NEWS: revert NEWS item for exclude tags for 0.12
e77b031 config: disable addition of exclude tags for 0.12
Formerly the xapian database object was deleted and closed in its
destructor once the object was garbage collected. Explicitly call
close() so that the database and the associated lock is released
immediately.
The comment is a courtesy of Austin Clements.
Signed-off-by: Justus Winter <4winter@informatik.uni-hamburg.de>
This is a small change to make notmuch.el ignore excluded matches. In
the future it could do something better like add a button for
rerunning the search with the excludes (particularly if nothing
matches with the excludes) or having them invisible and allowing the
visibility to be toggled.
