It's not working properly; the current message is jumping around and the
tags not really added/removed properly.
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
kill-this-buffer appears to be a function intended specifically for
use in the menu bar, and causes problem killing notmuch buffers when
multiple frames have been used. This patch replaces kill-this-buffer
with notmuch-kill-this-buffer, which in turn just simply calls
(kill-buffer (current-buffer)).
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 patch modifies the following commands to access the messages via
cat subcommand:
- view/save attachments ('v', 'w'),
- view a raw message ('V') and
- pipe a message to a command ('|').
With this patch, it is straightforward to use notmuch emacs interface
with a remote database accessed over SSH. To do this, it is sufficient
to redefine notmuch-command variable to contain the name of a script
containing:
ssh user@host notmuch "$@"
If the ssh client has enabled connection sharing (ControlMaster option
in OpenSSH), the emacs interface is almost as responsive as when
notmuch is invoked locally.
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).
This change affects both text and json formats. Now, text format
behaves as before commit 6dcb7592, but json format is changed.
Earlier, the empty search returned '[]', now it returns ''. The emacs
interface seems not to be affected by this change.
My scripts expect that empty search result is actually empty. Since
commit 6dcb7592, even empty search prints a newline character and this
breaks my scripts.
This patch adds a test for this bug. In the test I cannot use
test_expect_equal function as $() operator suppresses the final
newline and this kind of difference is not detected.
test/search | 5 +++++
1 files changed, 5 insertions(+), 0 deletions(-)
This is almost totally clearn. The (mangled) names of the Xapian
exception classes appear here. That's not actually desired, as the
notmuch library is never intended to throw any exceptions. But Xapian
does not currently provide a mechanism for us to avoid these.
This option wasn't having the desired effect, and sure enough, the
documentation states that it only affects the linking of libraries
that appear after this option on the command line. So put it early for
the desired effect.
This prevents any of the private functions from being leaked out
through the library interface (at least when compiling with a
recent-enough gcc to support the visibility pragma).
These various functions and data are all used only locally, so should
be marked static. Ensuring we get these right will avoid us accidentally
leaking unintended symbols through the library interface.
Previously, we were building the final binary with this option, but not
the library. The library can benefit from it as well, (as pointed out
by Debian's lintian).
This increment is for the recently-added functions:
notmuch_query_get_query_string
notmuch_query_get_sort
These were recently added to the library interface, but the library
version was not incremented at that time, (shame on me).
This fits with our general build philosophy of checking at configure
time for desired support, (rather than putting platform-specific
conditionals into our Makefiles).
Without this little patch notmuch fails if asked to display a saved
search that has zero results
Edited-by: David Edmondson <dme@dme.org>: With code that is a little
more "emacsy".
Re-write `notmuch-search-color-line', with the following improvements:
- create overlays only if they will be needed,
- merge the properties specified for a tag on top of any matching a
previous tag.
With this, users will be able to simply "apt-get install emacs" and
then "emacs -f notmuch" without having to edit ~/.emacs to add a
("require 'notmuch)".
Remove them from non-top-level entry points, (such as the functions to
set notmuch modes and the deprecated notmuch-folder function). And add
one to the notmuch-hello function. Also, add missing documentation
string to notmuch-hello.
Previously, we preferred a value of "xapian-config-1.1" first. This
was convenient for compiling against Xapian 1.1 while Xapian 1.2 was
unreleased. But now that Xapian 1.2 is realease, and since it ships a
xapian-config, the xapian-config-1.1 value can mask the newer library.
Instead of trying to track the latest xapian-config-1.x in our
configure script let's simply expect the user to set
XAPIAN_CONFIG=xapian-config-1.x in order to compile against an
unreleased Xapian.
Without this, trying to link with the gold linker would fail, (which meant
that notmuch could not be compiled out of the box on recent Fedora, nor
even on Debian when the binutils-gold package is installed).
