Rather than silently swallowing unexpected output, the emacs interface will now
display it. This will allow error messages to actually arrive at the emacs
interface (though not in an especially pretty way). This also allows for easier
investigation of the inadvertent swallowing of search results that span page
boundaries (as demonstrated by the recent added emacs-large-search-buffer test).
The page-boundary bug has been present since a commit from 2009-11-24:
93af7b5745
Many thanks to Thomas Schwinge for tracking that bug down and
contributing the test for it.
The new name is more descriptive of the bug being tested. Also, the test
is rewritten slightly so that it's much more plain to see how the bug
manifests itself, (that messages are droped from the emacs result at
regular intervals). Primarily, this is by collapsing the large blobs
used to inflate the message subjects.
In the original json code, search matching nothing would return a
valid, empty json array (that is, "[]"). I broke this in commit
6dcb7592e3 when adding support for
--output=threads|messages|tags. This time, while fixing the bug also
add a test to the test suite to help avoid future regressions.
Now that we understand the bug here, we rename this test to
search-insufficient-from-quoting to clarify the bug being exercised,
(which occurs when the From: line contains an unquoted '.' character).
We also mark these tests as expected failures until the bug gets fixed.
Currently, there are two places in the test framework that contain very
long list on a single line. Whenever a test is added (or changed) in
several branches and these branches are merged, it results in conflict
which is hard to resolve because one has to go through the whole long
line to find where the conflict is.
This patch splits these long lists to several lines so that the
conflicts are easier to resolve.
Currently, whenever we call index_terms multiple times for a single
field, the term generator is being reset to position 0 each time. This
means that with text such as:
To: a@b.c, x@y.z
one can get a bogus match by searching for:
To: a@y.c
Thanks to Mark Anderson for reporting the bug, (and providing a nice,
minimal test case that inspired what is used here).
This is a new feature which is not implemente yet, so these tests mostly
fail currently. A subsequent commit will add the feature and cause these
tests to start passing.
These tests verify that we can search for containing folders of mail files
by word or by phrase and that the search terms are updated correctly when
directories are renamed.
This reverts commit f22a7ec1e2.
Interrupting the test suite due to an actual bug in a test script
would be just fine, but interrupting the run of the entire test suite
at the first test failure is unacceptable.
Previously, this directory was only preserved for failing tests. But
it's important to be able to easily debug known-broken tests, so
preserve the actual vs. expected output for those as well.
Use varying dates in the test messages to test the order authors are
listed in. Add tests with repeated author names and unusual date
ordering. Most of these are broken at the moment, but will be fixed
shortly.
Edited-by: Carl Worth <cworth@cworth.org>: Also update the expected
results for existing emacs tests that currently codify the incorrect
author ordering, (and similarly note them as broken in the current
test suite).
Incremental search does not match strings that span a
visible/invisible boundary. This results in failure to correctly
isearch for authors in `notmuch-search' mode if the name of the author
is split between the visible and invisible components of the authors
string. To avoid this, attempt to truncate the visible component of
the authors string on a boundary between authors, such that the
entirety of an author's name is either visible or invisible.
When a test fails, a tmp.<testname> file is left behind. These files
are useful for the person debugging the test failure, but are never
anything we want to commit.
Edited-by: Carl Worth <cworth@cworth.org>: Changed from tmp.emacs to
tmp.* and added explanation in the commit message.
This testing *does* capture the bug of missing '[' and ']' characters
int "notmuch search --output=tags" case. This is another manifestation
of the same bug causing the missing final newline (as mentioned in the
previous commit).
This code simply wasn't being exercised by the test suite before, so
this will be useful.
Meanwhile, there's currently a bug in "notmuch search --output=tags"
in that it doesn't print a final newline. But the current test suite
isn't able to catch this bug since the $() construct of the shell
doesn't preserve the distinction of whether the final newline is
present or not.
This test script does some initial test setup (generating a few
messages), which is all well and good, but we don't need to print that
as a test result---particularly since the test result was effectively
hard-coded to always pass.
When test_begin_subtest is not followed by corresponding test_expect_equal,
the output of the rest of the test script is errornously suppressed. Add
code to detect these bugs in test scripts.
Break notmuch-test whenever a test script returns non-zero status.
This happens either when some test from the script fails or when there
is an error in the script.
This is especially useful in the latter case since the error may not
appear in the final aggregated results.
The newline was removed from say_color in commit 222926ab to allow
printing test status in the beginning of the line. Error messages are
never followed by other text so we add the newline to error function.
Git-style tests (test_expect_success etc.) suppress stdout and stderr
unless -v is given. Notmuch-style tests (created by test_begin_subtest
and test_expect_equal) do not have this behavior so implement it the
same.
Additionally, for both test styles, the test-lib.sh is changed so that
the content of suppressed stdout and stderr is shown in case of failed
test.
Finally a test for this functionality is added to basic tests.
This is to prevent notmuch from destroying any information the user
has encoded as flags in the maildir filename. Tests are also added to
the test suite to verify the documented behavior.
Some people use notmuch with non-maildir files, (for example, email
messages in MH format, or else cool things like using sluk[*] to suck
down feeds into a format that notmuch can index).
To better support uses like that, don't do any renaming for files that
are not in a directory named either "new" or "cur".
[*] https://github.com/krl/sluk/
The FCC code saves a message in maildir format, and sets the S flag by
default, so now, automatically, FCC messages will not show up as
"unread", (which seems natural enough).
There's nothing in the current API documentation that would suggest
the behavior being tested here. Attempt to implement this could have
some nasty side effects, (such as notmuch_message_maildir_flags_to_tags
implicitly calling notmuch_message_tags_to_maildir_flags and maybe
even opening up some bad looping possibilities).
Much better to stick with what we have documented, which we believe will
actually be useful, (and easy enough to comprehend).
These needed to be changed to be brought up to the current state of
the maildir-sync tests. This includes style changes, but also the
elimination of any assumption about pre-existing message filenames,
(such as msg-003) which actually don't exist anymore.
Also, the known broken tests are changed to emit FAIL rather than
BROKEN simply to make them easier to fix, (so that they print the
current problems rather than hiding them).
Finally, an additional test is added to ensure that when a duplicate
file is added without flags, it doesn't invalidate flags from other
duplicates, (instead the flags are effectively merged).
Add maildir synchronization tests for multiple messages with the same
message-id. As this is not yet implemented in notmuch, some of these
teste are marked as BROKEN.
I use $(< ) operator to avoid fiddling with stripped trailing newlines
from test results which happens when output+=$(command) is used.
This change reworks these tests in several ways:
1. Bring tests into "new" test style preferring test_expect_equal over
test_expect_success in almost all cases.
2. Don't emit test results for intermediate items not actually being
tested, (things like "no new messages", "search for message",
etc.). Those things are already covered by existing tests such as
"basic" or "search" and only serve to obscure what's actually being
tested.
3. Change sense of the test showing failure to rename a file from
"new" to "cur" when "cur" doesn't exist.
In this case, notmuch should detect that this is not a maildir and
should not attempt to do any renaming of the file.
4. Extend dump/restore test to also exercise addition of tag, not just
removal.
Both items #3 and #4 above show shortcomings in the current
implementation. These are currently resulting in test results of FAIL
and indicate bugs that need to be fixed.
We have test names like maildir-sync now, so it's cleaner if the
temporary files created are named things like maildir-sync-10.out
rather than maildir-10.out. Presumably the extra stripping here came
from naming conventions in git's test suite.
This is part of an effort to avoid proliferation of excessive
top-level notmuch commands. Also, "raw" better captures the
functionality here, (as opposed to "cat" which is a fairly oblique
reference to a bad Unix abbreviation whose metaphor doesn't work here
since "notmuch cat" operates only on a single message and hence cannot
"con'cat'enate" anything).
This command outputs a raw message matched by search term to the
standard output. It allows MUAs to access the messages for piping,
attachment manipulation, etc. by running notmuch cat rather then
directly access the file. This will simplify the MUAs when they need
to operate on a remote database.
Edited-by: Carl Worth <cworth@cworth.org>: Remove trailing whitespace,
add missing "test_done" to new test script to avoid "Unexpected exit"
error.
This was too rude of a thing to do and could easily introduce
problems, (as reported by Rob Browning whose environment required some
HOME-specific things for shell startup).
Instead, implement more focused changes to ensure that particular file
in $HOME don't cause problems. Specifically, we fix known problems
with ~/.signature and ~/.mailrc here.
The original mails used to pupulate the mail corpus had had their
attachments (obnoxiously) scrubbed by the pipermail mail archiver.
Since we actually want to test the handling of attachments, this is
less than useful. Restore these files from my own collection, (with
some Received and similar headers pruned).
I still don't know everything about how I want search order to be
customizable, but I do like the current defaults, (namely, performing
a new search gives results newest first, but performing a saved search
like "tag:inbox" gives results as oldest first).
Until we come up with a better plan for people to select what *they*
want, (rather than just getting what I want), let's codify the current
results in the test suite.
After any emacs test failure, the tmp.emacs directory will have this
run_emacs script in it which the user can use to run emacs within the
test suite environment, (pointing at the test suite's notmuch
database, using the local notmuch command-line program, and the local
notmuch emacs lisp code).
