At the moment, the test-lib fills in any missing headers. This makes
it impossible to test our handling of empty subjects. This will
allow us to use a special dummy subject -- `@FORCE_EMPTY` -- to force
the subject to remain empty.
We generally do not support mbox files, but for historical reasons
we've supported single-message mbox files, with a deprecation
message. We've tried dropping the support altogether, but backed out
of it because we'd need to stop indexing them, while keeping support
for previously indexed files. This would be more complicated than
simply supporting single-message mbox files. Therefore, drop the
deprecation message, and just silently accept single-message mboxes.
Currently, if a From-header is of the form:
"" <address@example.com>
the empty string will be treated as a valid real-name, and the entry
in the search results will be empty.
The new behavior here is that we treat an empty real-name field as if
it were null, so that the email address will be used in the search
results instead.
Signed-off-by: Jesse Rosenthal <jrosenthal@jhu.edu>
We test for whether a quoted empty email address
"" <address@example.com>
will show up as the address, instead of the empty string. This is
marked as known-broken, since the current behavior is to use the empty
string.
This is a new test file, since handling of unusual email addresses
doesn't seem to fit well in any of our existing tests.
Signed-off-by: Jesse Rosenthal <jrosenthal@jhu.edu>
When no --output option were given, change default to display senders
only.
When only --count option is given, display senders (in contrary to not
displaying anything).
Document that --count with --sort=**order** is not supported option
combination.
Clean up some whitespace in the documentation.
One test updated to have --output=count without sender nor recipient
output option.
This filters out duplicate addresses from address command output.
It also also adds tests for the address command.
The code here is an extended version of a patch from Jani Nikula.
python3 doesn't allow dictionaries to be initialized with non-string
keywords. This presents problems on systems in which "python" means
"python3". We instead initalize the dictionary using the dict
comprehension and then update it with the values from the tree. This
will work with both python2 and python3.
Apparently the test binaries are built with minimal LDFLAGS, only
adding dependency specific LDFLAGS as needed. However because some of
the test binaries incorporate notmuch object files, it is necessary to
use the same link flags as notmuch. For example user provided
CFLAGS/CXXFLAGS/LDFLAGS with -fsanitize=undefined fails to build the
test binaries if the flags differ.
In emacs 24.4 the messages buffer starts being read-only, which kills
these tests. This seems to be the point of the variable
inihibit-read-only, which has existed at least since emacs 21.
After yet another variation in objdump output caused this test to fail
(on a Debian port, no less), I decided whatever putative benefit we
get from looking at the object files instead of the library isn't
worth the maintenence headache.
This version uses nm -P. nm -P should be portable, and fixed format.
It purposely doesn't use the -D argument, since that is non-POSIX and
nm on GNU/Linux seems do the right thing without it.
It still won't work out of the box on e.g. Mac OS/X. I think the right
thing to do there is to move some more configuration information into
sh.config.
(cherry picked from commit c34d6bad0f)
Previously, this was implemented using a horrible GDB script (because
there is no such thing as a non-horrible GDB script). This GDB script
often broke with newer versions of GDB for mysterious reasons. Port
the test script to GDB's Python API, which makes the code much cleaner
and, hopefully, more stable.
(cherry picked from commit cbbda62258)
Conflicts:
test/T380-atomicity.sh
Add --keep option to keep any remaining stuff in index or file. We
could distinguish between failures to index and failures to apply tags
or maildir sync, but for simplicity just have one.
Previously, this was implemented using a horrible GDB script (because
there is no such thing as a non-horrible GDB script). This GDB script
often broke with newer versions of GDB for mysterious reasons. Port
the test script to GDB's Python API, which makes the code much cleaner
and, hopefully, more stable.
In the future, tests may rely on debug symbols being present in
notmuch, so we plan to switch the default flags.
The main purpose of this test is to help explain the perhaps
mysterious failures of other tests which rely on symbols being
present.
The test of viewing 8bit messages is known-broken. The rest pass, but
for very fragile reasons. The next several commits will fix the
known-broken test and make our charset handling robust.
Previously we did this for a single test, but some other proposed
tests ( id:1398105468-14317-3-git-send-email-amdragon@mit.edu ) show
similar breakage when switching renderers.
After yet another variation in objdump output caused this test to fail
(on a Debian port, no less), I decided whatever putative benefit we
get from looking at the object files instead of the library isn't
worth the maintenence headache.
This version uses nm -P. nm -P should be portable, and fixed format.
It purposely doesn't use the -D argument, since that is non-POSIX and
nm on GNU/Linux seems do the right thing without it.
It still won't work out of the box on e.g. Mac OS/X. I think the right
thing to do there is to move some more configuration information into
sh.config.
Previously, if the user ran any subcommand that required a
configuration (e.g., notmuch new) but didn't have a configuration,
notmuch would give the rather un-friendly and un-actionable message
Error reading configuration file .notmuch-config: No such file or directory
Since this condition is expected for new users, this patch adds
specific handling for the file-not-found case to give a message that
is friendly and actionable.
The version number has always been pretty meaningless to the user and
it's about to become even more meaningless with the introduction of
"features". Hopefully, the database will remain on version 3 for some
time to come; however, the introduction of new features over time in
version 3 will necessitate upgrades within version 3. It would be
confusing if we always tell the user they've been "upgraded to version
3". If the user wants to know what's new, they should read the news.
According to RFC2822 References and In-Reply-To headers are supposed
to contain one or more Message-IDs, however older RFC822 allowed
almost any content. When both References and In-Reply-To headers ends
with something else that a Message-ID (see e.g. [1]), the thread
structure presented by notmuch is incorrect. The reason is that
notmuch treats this case as if the email contained no "replyto"
information (see _notmuch_database_link_message_to_parents).
This patch changes the parse_references() function to return the last
valid Message-ID encountered rather than NULL resulting from the last
hunk of text not being the Message-ID.
[1] https://lkml.org/lkml/headers/2014/5/19/864
Previously the build system was generating automatic header
dependencies for test sources, but only smtp-dummy was in SRCS, so
only its dependencies were being included. Add all of the test
sources to SRCS so that the root Makefile.local includes their
dependencies.
This should help new users off to a better start with the addition of
more sensible saved searches and default shortcut keys. Most existing
users have probably customized this variable and won't be affected.
Dump currently only takes the read lock. Xapian can cope with some
changes while maintaining a read snapshot but with more changes it
fails. Currently notmuch just gives a xapian error.
To avoid this we take the write lock when dumping. This prevents other
notmuch processes from modifying the xapian database preventing this
error.
Discussion with Olly on irc indicates that this is currently the best
solution: in xapian trunk there may be better possibilities using
snapshots but they need to make it to a release and propogate out to
users before we can switch approach.
Finally, this breaks one use case: pipelines of the form
notmuch dump | ... | notmuch restore
According to Olly this is already very fragile: it will only work on
small databases. One of the tests relies on this behaviour so fix that
to store the dump rather than use a pipe.
These tests deliver all possible (single-root) four-message threads in
all possible orders and check that notmuch successfully links them
into threads. These tests supersede and replace the previous and much
less thorough "T260-thread-order" tests.
There are two variants of the test: one delivers messages that
reference only their immediate parent and the other delivers messages
that reference all of their parents. The latter test is currently
known-broken.
The unread/read changes will use the post-command-hook. test_emacs
does not call the post-command-hook. This adds a notmuch-test-progn
which takes a list of commands as argument and executes them in turn
but runs the post-command-hook after each one.
The caller can batch operations (ie to stop post-command-hook from
being interleaved) by wrapping the batch of operations inside a progn.
We also explicitly run the post-command-hook before getting the output
from a test; this makes sense as this will be a place the user would
be seeing the information.
This adds a 100 termpos gap between all phrases indexed by
_notmuch_message_gen_terms. This fixes a bug where terms from the end
of one header and the beginning of another header could match together
in a single phrase and a separate bug where term positions of
un-prefixed terms overlapped.
This fix only affects newly indexed messages. Messages that are
already indexed won't benefit from this fix without re-indexing, but
the fix won't make things any worse for existing messages.
This adds two known-broken tests and one working test related to the
term positions assigned to terms from different headers or MIME parts.
The first test fails because we don't create a termpos gap between
different headers. The second test fails because we don't adjust
termpos at all when indexing multiple parts.
Previously, we indexed the name and address parts of from/to headers
with two calls to _notmuch_message_gen_terms. In general, this
indicates that these parts are separate phrases. However, because of
an implementation quirk, the two calls to _notmuch_message_gen_terms
generated adjacent term positions for the prefixed terms, which
happens to be the right thing to do in this case, but the wrong thing
to do for all other calls. Furthermore, _notmuch_message_gen_terms
produced potentially overlapping term positions for the un-prefixed
copies of the terms, which is simply wrong.
This change indexes both the name and address in a single call to
_notmuch_message_gen_terms, indicating that they should be part of a
single phrase. This masks the problem with the un-prefixed terms
(fixing the two known-broken tests) and puts us in a position to fix
the unintentionally phrases generated by other calls to
_notmuch_message_gen_terms.
Two of these are currently known-broken. We index the name and
address parts in two separate calls to _notmuch_message_gen_terms.
Currently this has the effect of placing the term positions of the
prefixed terms from the second call right after those of the first
call, but screws up the term positions of the non-prefixed terms.
Two of the search tests for "from" and "to" queries were clearly
trying to search for prefixed phrases, but forgot to shell quote the
phrases. Fix this by quoting them correctly.
