These new tests demonstrate a bug as follows:
Multiple messages are added to the database
All of these message references a common parent
The parent message does not exist in the databas
In this scenario, the messages will not be recognized as belonging to
the same thread. We consider this a bug, and the new tests treat this
as a failure.
Edited by Carl Worth <cworth@cworth.org>: Split these tests into their
own commit (before the fix of the bug). This lets me see the actual
failure in the test suite, before the fix is applied. Also fix the
alignment of new messages from test suite, (so that the PASS portions
all line up---which is important while we're still manually verifying
test-suite results).
I often have several versions of notmuch compiled and it would be very
helpful to be able to distinguish between them. Git has a very nice
feature to make intermediate numbering automatic and unambiguous so
let's use it here.
For tagged versions, the version is the name of the tag, for
intermediate versions, the unique ID of the commit is appended to the
tag name.
When notmuch is compiled from a release tarball, there is no git
repository and therefore the tarball contains a special file 'version',
which contains the version of release tarball.
To create a new release one has to run 'make release VERSION=X.Y'.
From both the implementation and from the documentation. This is
handled generically in the library for all search-based commands,
so count doesn't need special treatment.
This seems like a generally useful thing to support, (but the previous
support through an empty string was not convenient for some users,
(such as the command-line client).
If no parameters are given to notmuch-count, or just '' or '*' are
given, return the total number of messages in the database.
update notmuch count help
The previous code made too many assumptions about the (sadly not
standardized) format of the Received headers. This version should
be more robust to deal with different variations.
Signed-off-by: Dirk Hohndel <hohndel@infradead.org>
These commands act on all messages in the thread, not simply those
that match the search. (There are use case for both behaviors, but the
documentation must match the behavior that's actually implemented).
This patch adds `-region' versions of the `notmuch-search-' commands to find
properties. It also splits up `notmuch-add/remove-tags' into both a
`-thread' and a `-region' version. (This makes us modify
`notmuch-search-archive-thread' to use the
`notmuch-search-remove-tag-thread' function, instead of
`notmuch-search-remove-tag', for consistency.) The add/remove-tag command
called by pressing `+' or `-' will then choose accordingly, based on whether
region is active.
This version fixes a couple of errors in the first version, which led to
incorrect marking of some tags in the search view (though the actual
tagging was still correct). It's also based on current master.
I'm not sure any more if region selection is actually the correct way to
do this, or if a mutt-style message-marking method would be better. But
I didn't want a buggy incorrect version out there.
As put forth in the commit that enabled this functionality, the last
few lines of a citation are often much more important. In that case,
let's actually do the useful thing by default.
In many conversations the last few lines of a citation are more
interesting than the first few lines, hence allow those to be shown if
desired.
Signed-off-by: Sebastian Spaeth <Sebastian@SSpaeth.de>
Arbitrary font faces can be specified for given thread tags. By
default, no coloring is applied. To specify coloring, place something
like this in your .emacs:
(setq notmuch-search-line-faces '(("delete" . '(:foreground "red"))
("unread" . '(:foreground "green"))))
Order matters: line faces listed first will take precedence (in the
example above, a thread tagged both "delete" and "unread" will be
colored red, since the "delete" face is listed before the "unread").
notmuch.el | 33 ++++++++++++++++++++++++++++++++-
1 files changed, 32 insertions(+), 1 deletions(-)
Change the buffer name to a uniquified subject of the thread (i.e. the
subject of the first message in the thread) instead of the thread-id. This
is more meaningful to the user, and will make it easier to scroll through
numerous open buffers.
Note that this patch adds an optional `buffer-name' argument to notmuch
show.
Signed-off-by: Jesse Rosenthal <jrosenthal@jhu.edu>
Signed-off-by: Sebastian Spaeth <Sebastian@SSpaeth.de>
The date was unfairly left out of getting pretty colors in the
notmuch-show header display. This fixes that grave injustice.
Signed-off-by: Sebastian Spaeth <Sebastian@SSpaeth.de>
And just make the Debian packaging request site-lisp/notmuch like it
wants. Otherwise, the installed files won't appear on the load-path
so won't be found by emacs.
When replying to a message notmuch tries to pick the correct From
address by looking which one of a user's configured email addresses
were included in To or Cc headers of the email that is being replied to.
If none of the users email addresses are in the To or Cc headers we now
try to guess from the first (chronologically, last) Received header
which domain this email was received in and therefore which of the
email addresses to use in a reply
If that fails we still use the primary email as From email
Signed-off-by: Dirk Hohndel <hohndel@infradead.org>
fix notmuch_message_file_get_header to always return the first instance
of the header you are looking for
Signed-off-by: Dirk Hohndel <hohndel@infradead.org>
These are the changes made between the notmuch 0.1 release and the
release of Debian version 0.1-1. It's mostly changes to the debian
directory, of course, but does also include some generally useful
Makefile improvements.
We currently don't distribute anything that's not already in git, so
there's no difference between these two targets, (but debhelper wants
to be able to call distclean).
Which means that the bash completion script will now install
to ${prefix}/etc by default (unless configured with --syconfdir=/etc)
which is probably the right thing to do.
I'm not sure that this option would actually be useful for anything,
but debhelper at least expects our configure script to support it. So
we'll accept it and ignore it.
Most anyone familiar with debian should know to look for the top-level
debian directory, but since we do have a "packaging" directory, I
thought it should at least mention the debian stuff rather than just
containing the fedora spec file.
