I had previously thought Xapian only offered an estimate for the
number of results that might match a search. But Olly let me know
that we can easily ask for Xapian to provide the exact count.
Database.find_message() used to be able to reliably indicate whether a
message exists or not (in which case it returns None). However, the
recent API change of the notmuch library means we will return None
even for all Xapian exceptions, which happens e.g. when the current
Database has been modified by another project. Therefore the return
value of None cannot be reliably be used to indicate whether a message
exists or not. Make the docs state that explicitely.
Signed-off-by: Sebastian Spaeth <Sebastian@SSpaeth.de>
I wish I had something with better support for a native Debian package
here. I shouldn't ever have to configure any branch---I just want it
to build a package from the current branch. Instead it makes me tell
it (twice!) what the current branch actually is.
"Still needs to be handled correctly" could be misread to suggest that
the bug has not actually been fixed yet. So clarify what is actually
meant here, (that the bug is unlikely but we're still motivated to fix
it).
Admittedly, an author name ending in ',' guarantees this is spam, and
indeed this was triggered by a spam email, but that doesn't mean we
shouldn't handle this case correctly.
We now check that there is actually a component of the name (presumably
the first name) after the comma in the author name.
Signed-off-by: Dirk Hohndel <hohndel@infradead.org>
This doesn't pull in any code, (everything in 0.3.x was originally
cherry-picked from master anyway). But the merge does give us a
correct NEWS file showing which fixes are included in 0.3.1 and which
features have been commited "since" then, (topologically, not
chronologically).
This fixes a build error on OpenSolaris where the final liking of
notmuch fails because the linker can't find strcasestr() referenced
from thread.cc.
(cherry picked from commit aab54b4ce7)
The fcc code would only initialize if notmuch-fcc-dirs was set. This was
a problem if you reset the variable, or added the variable later during
initialization. Now we always add the fcc hook, but it doesn't do
anything unless notmuch-fcc-dirs are set.
(cherry picked from commit 80a9078716)
The fix in 1e18711543 broke end-of-row
wrapping when drawing the table of tags/saved searches. Fix that and
improve the readability of the matrix reflection code to hasten future
debugging.
(cherry picked from commit 08561d8ae1)
If the 'all tags' section of the hello buffer will not be shown, don't
consider those tags when determining the number of saved searches that
can be displayed on a single line.
(cherry picked from commit 18d41192d2)
i is already used in a for loop at this point, so using i here again
broke notmuch-reply (it would just hang). Use j instead of i here.
Signed-off-by: Sebastian Spaeth <Sebastian@SSpaeth.de>
(cherry picked from commit 107f58d517)
Immediately after releasing 0.3 we learned that the magic-from-guessing
code could hang in an infinite loop in some cases. The bug occurred
only when the user had configured only a primary email addresss and no
other email addresses.
The test suite wasn't previously covering this case, so address this
shortcoming.
(cherry picked from commit e0f5610498)
Immediately after releasing 0.3 we learned that the magic-from-guessing
code could hang in an infinite loop in some cases. The bug occurred
only when the user had configured only a primary email addresss and no
other email addresses.
The test suite wasn't previously covering this case, so address this
shortcoming.
The fcc code would only initialize if notmuch-fcc-dirs was set. This was
a problem if you reset the variable, or added the variable later during
initialization. Now we always add the fcc hook, but it doesn't do
anything unless notmuch-fcc-dirs are set.
Add a (require 'notmuch-message) to notmuch.el. This is for functions that
specifically target message mode (and, in the future, notmuch-message
mode).
Add `notmuch-message-mark-replied', a function for automatically tagging
replied messages with user-defined tags. The tags (which can be either
added or removed) can be customized with the customization variable
`notmuch-message-replied-tags'. This is a simple list of strings. Any
string prefaced with a "-" will be removed; any string prefaced with a "+"
(or neither "+" nor "-") will be added.
This adds a new file notmuch-message.el, for functions which target
message mode (and in the future, notmuch-message mode). Based on some
conversation, notmuch-message.el will probably end up subsuming
notmuch-mua.el, but until we figure out exactly how we want to do that,
they will remain separate files.
Edited-by: Carl Worth <cworth@cworth.org>: Remove trailing whitespace
and add newline at end of file.
Detect inline patches and convert them to fake attachments, in order
that `diff-mode' highlighting can be applied to the patch. This can be
enabled by customising `notmuch-show-insert-text/plain-hook'.
The fix in 1e18711543 broke end-of-row
wrapping when drawing the table of tags/saved searches. Fix that and
improve the readability of the matrix reflection code to hasten future
debugging.
If the 'all tags' section of the hello buffer will not be shown, don't
consider those tags when determining the number of saved searches that
can be displayed on a single line.
i is already used in a for loop at this point, so using i here again
broke notmuch-reply (it would just hang). Use j instead of i here.
Signed-off-by: Sebastian Spaeth <Sebastian@SSpaeth.de>
Otherwise lintian thinks this is an NMU. I definitely need to figure
out how to get the emacs mode for debian/changelog to write the
correct address into this file in the first place.
Re-working the saved search/tag insertion to buttonize only the name
of the saved search/tag plus one space broke the calculation of how
much filler is required to complete the column, resulting in lines
wider than the window.
Just before releasing 0.3 we received reports of crashes that were
bisected to the commit adding thread-author moving. Sure enough,
valgrind pointed to buffer overruns in _thread_move_matched_author.
Rather than trying to make sense of all the by strncpy, strchr, +1,
and +2 of that code, I reimplemented thread-author ordering with a
pair of hash tables and an array.
Valgrind is at least happy now on the test cases it was complaining
about previously.
It's possible that the user has instructed message-mode to use some
other separator. If so, then that's what we should look for when
looking for the signature.
Thanks to David Edmondson <dme@dme.org> for pointing this out.
If the user specifies a maildir that does not exist, prompt the user to
see whether a maildir should be created. This will fail, with the
relevant explanation, if the location is not writable, or if a file
already exists in that location. If the location is a dir, but not a
maildir, this will add /tmp/cur/new to it.
Throw an error after the maildir is generated but before the message
is sent. This change allows the user to edit the maildir if it fails,
so that it will point to a correct place.
Note that this changes the previous behavior which always overwrote
the existing Fcc line. Now, an Fcc line is only auto-generated if
there isn't one already there.
The ideal change would be to prompt to create a maildir. This should
enable a place for doing that in a future patch.
The complete-string matching of commit
f2ebe3ac44
defeats the substitution of partial search
strings when the user manually types a
long search string that just happens to
partially match a saved search.
For example, typing "tag:inbox and not tag:foo"
should result in "[inbox] and not tag:foo" but
this has been broken since that commit.
As a compromise between this feature and what the
commit was trying to achieve, we now reverse the
saved-searches list before looking for a match.
This happens to work for me, but won't necessarily
work in general.
What we really want is the longest match, but rassoc-if
just gives us the first match. All of this is just about
creating slightly nice search-buffer names. So if anyone
really cares about making the names *even* nicer, then
they could improve this further.
I happen to have a lot of saved searches that are variants of the
tag:inbox search, (such as "tag:inbox and tag:notmuch"). The logic for
these was always matching inbox first, resulting in "[ inbox ] and
tag:notmuch" rather than "notmuch" as desired.
Anchor the regular expression on both ends to make it look harder for
the better match.
We are asserting that the new notmuch-hello implementation, (available
by just calling `notmuch') is just as easy to use as the old
notmuch-folder. So let's remove what's now a largely redundant
implementation.
To make this transition easier, we are still supporting the
notmuch-folders variable name, and we still provide `notmuch-folder'
as an alias which can be invoked to get the new notmuch-hello
functionality.
Previously, this was calling into a notmuch-folder-count
function. Only, everything related to notmuch-folder is about to go
away, so lets have notmuch-hello define its own function
(notmuch-saved-search-count) for this purpose.
