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).
Hi,
If I want to build Debian package, it fails with the following message:
ldconfig: Can't create temporary cache file /etc/ld.so.cache~: Permission denied
make[1]: *** [install-lib] Error 1
The reason is that I build the package as a non-root user and make
install invokes ldconfig unconditionally. The following patch contains a
workaround, but I think that a more correct solution would be to check
the condition LIBDIR_IN_LDCONFIG directly when make install is invoked
rather than in configure as it is done now.
Signed-off-by: Michal Sojka <sojkam1@fel.cvut.cz>
The bash code in the test suite is using associative arrays which were
only added to bash as of release 4.0.
If the test suite is run with an older bash, we now immediately error
out and explain the situation, (instead of emitting confusing error
messages and failing dozens of tests, which is what happened before
this change).
Some recently-added tests used hard-coded thread ID values in search
specifications. This is unreliable since the thread IDs depend on the
order in which "notmuch new" encounters new files, (which in turn can
depend on inode ordering within the filesystem).
Fix these by using the new "notmuch search --output=threads" to find the
correct thread IDs given a hard-coded (but reliable) message ID.
I don't see copy-seq documented within emacs at all, and some users
have encountered failures of the form:
notmuch-show-del-tags-worker: Symbol's function definition is void: copy-seq
This should eliminate that problem.
The original code was intended to work, but clearly wasn't tested. Use
mail-header (as in existing code) to extract a header from a header alist.
This fixes the duplicate-from-line bug that is exercised by the test
just added to the test suite.
The reply is primarily taken care of by "notmuch reply" which is already
thoroughly tested. But a recent bug is inserting a duplicate From header
in the emacs-based reply. So exercise that bug here.
These were introduced as a side-effect of commit
b9eac48c22 (shame on me for doing
side-effect commits like that!).
For me, at least, compilation is now warning-free.
Yet another case of "how could this have possibly worked before?!".
I guess we were just getting very lucky with the emacs lisp calling
conventions and what happens with extra arguments, but, ick! Much
better now.
As the emacs compiler warns, the goto-line function is only intended for
interactive use. Instead use the approach recommended in the goto-line
documentation to avoid this.
This is one of those cases where the warning looks absolutely correct,
(complaining about a free variable), but I'm left wondering how the
original code could have worked at all.
From what I can tell, this code wasn't actually being called by any
of the current code in notmuch.
The GNU Emacs Lisp Reference Manual section D.1 says:
> * Please don't require the cl package of Common Lisp extensions at
> run time. Use of this package is optional, and it is not part of
> the standard Emacs namespace. If your package loads cl at run time,
> that could cause name clashes for users who don't use that package.
>
> However, there is no problem with using the cl package at compile
> time, with (eval-when-compile (require 'cl)). That's sufficient for
> using the macros in the cl package, because the compiler expands
> them before generating the byte-code.
Follow this advice, requiring the following changes where `cl' was
used at runtime:
- replace `rassoc-if' in `notmuch-search-buffer-title' with the `loop'
macro and inline code. At the same time find the longest prefix
which matches the query rather than simply the last,
- replace `union', `intersection' and `set-difference' in
`notmuch-show-add-tag' and `notmuch-show-remove-tag' with local code
to calculate the result of adding and removing a list of tags from
another list of tags.
Call notmuch-fcc-header-setup from message-header-setup-hook rather
than message-send-hook. This allows you to see what's going to
happen, and to make manual adjustments if desired. Gnus does
something similar.
Signed-off-by: Rob Browning <rlb@defaultvalue.org>
Update the tests so that they no longer expect the Bcc header in the
output of "notmuch reply" now that it has been removed.
Edited-by Carl Worth: Simply applying the change to our newly
modularized test suite.
Notmuch reply should not be Bcc'ing the sender by default. This is
not the appropriate way to save copies of sent mail (which should
probably be handled by an Fcc header[*]) and it doesn't give the user the
option to not be bcc'd. This is really something that should be
handled by the reader UI. For instance, emacs message-mode can easily
be configured to add Bcc's if the user wishes.
[*] Carl Worth: The FCC header is now in place by default in the emacs
user-interface (and tested in the test suite) so the Bcc is ready to
be eliminated.
We test that the message we sent via (fake) SMTP is included in the mail
index after a "notmuch new". This verifies that the FCC setting indeed
successfully saved the sent message within the notmuch mail store.
Simply setting an explicit date is cleaner than letting the current,
(arbitrary), date get generated for the email message and then constantly
filtering that date out of search results.
Now that the FCC code is fixed to use the notmuch database path, we can
actually enable this by default, which should be highly useful for all
new users of notmuch.
Otherwise, FCC is too hard to use, (user must set it and also set message-
directory variable to match notmuch mail datbase path). As a rule, I'd like
for users of notmuch to not be required to muck around with non-notmuch
mail settings in emacs.
The above is only really possible now thanks to the recent addition of the
"notmuch config get" command which allows emacs to query the currently
configured notmuch database path.
This also now allows an absolute-path FCC to be set if desired.
