We only rarely need to actually open the database for writing, but we
always create a Xapian::WritableDatabase. This has the effect of
preventing searches and like whilst updating the index.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Acked-by: Carl Worth <cworth@cworth.org>
Write down the steps needed to install and actuall use notmuch in emacs. Should
help emacs newbies.
Signed-off-by: Stefan Schmidt <stefan@datenfreihafen.org>
This reverts commit 9794f19017.
The feature makes a lot of sense for the initial import, but it's not
as clear whether it makes sense for ongoing "notmuch new" runs. We
might need to make this opt-in by configuration.
This patch adds maildir directory name as the tag name for
messages. This helps in adding tags using filtering already
provided by procmail.
Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
When pkg-config can't be used to find out where to install emacs
files, we fallback to a hard-coded directory. Only, we were falling
back to the wrong thing, (one that emacs doesn't look into by
default).
This was a bug that was introduced in copying the indexing code over
into notmuch-show.c. When indexing, we want to ignore the signature,
(it has no interesting terms). But when presenting the message, it's
important to present the signature to the user.
(And would be even better if we presented whether or not the signature
is good.)
In my script containing a series of queries to be run on new mail for
setting up tags, it's nice to see which query I typed wrong.
Signed-off-by: Eric Anholt <eric@anholt.net>
More fallout from _get_header now returning "" for missing headers.
The bug here is that we would no longer detect that a file is not an
email message and give up on it like we should.
And this time, I actually audited all callers to
notmuch_message_get_header, so hopefully we're done fixing this
bug over and over.
There's been a fair amount of fallout from when we changed
message_file_get_header from returning NULL to returning "" for
missing headers. This is yet more fallout from that, (where we were
accepting an empty message-ID rather than generating one like we want
to).
All objects need to be recompiled when any of the Makefiles changes, so
we make them all depend on all the Makefiles.
Signed-off-by: Jan Janak <jan@ryngle.com>
Avoding these is nicer to users, text editors, and our poor little
notmuch.el code itself that would get confused when seeing a copy of
itself in email. (Of course, we should still fix that bug, but this
workaround is good nonetheless.)
This was added in a prelimnary version of a previous commit that would
automatically load notmuch.el for anyone running emacs. It's not used
at all in the current Makefile.
This eliminates a crash when a message (either corrupted or a non-mail
file that wasn't properly detected as not being mail) has no In-Reply-To
header, (and so few terms that trying to skip to the prefix of the
In-Reply-To terms actually brings us to the end of the termlist).
This will add an entry in your window manager's menus that will create
up a new emacs process and start notmuch.
Signed-off-by: Jeffrey C. Ollie <jeff@ocjtech.us>
1) Add a separate targets to build and install emacs mode.
2) Don't hardcode the installation directory, instead use emacs'
pkg-config module.
3) Install a byte compiled version of the emacs mode.
4) Install the emacs mode in emacs' site-lisp directory. Put
"(require 'notmuch)" in your .emacs to load it automatically.
5) Ignore byte-compiled emacs files.
Signed-off-by: Jeffrey C. Ollie <jeff@ocjtech.us>
Reviewed-by: Ingmar Vanhassel <ingmar@exherbo.org>
Reviewed-by: Keith Packard <keithp@keithp.com>
This patch add notmuch-search-hook that gets run when we
after displaying search results
Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
Cc:Keith Packard <keithp@keithp.com>
As suggested by Keith in FLAG_PURE_NOT allows for expressions like:
notmuch search NOT tag:inbox
Note that this way a search like:
notmuch search foobar NOT tag:inbox
should not be written instead:
notmuch search foobar AND NOT tag:inbox
In my opinion, the latter feels more natural and is somewhat more explicit.
It gives a better clue of what the search is about instead of assuming that
an implicit AND operator is there.
