It's a simple optimization to look at a message and check that the
existing tags are actually different than the tags we are setting
before we do anything.
For my mail store this takes a "notmuch restore" that does nothing
from about 10 minutes down to 1 minute, so there's a significant
speedup here.
We do this all the time, but at least emacs is kind enough to remind us,
(when compiling), that next-line is only intended for interactive use,
and we should use forward-line inside of lisp code.
I really missed this feature. Added notmuch-show-toggle-current-body and
notmuch-show-toggle-current-header and bind them to 'b' and 'h'.
Signed-off-by: Kan-Ru Chen <kanru@kanru.info>
These tests were surprisingly simple to write---not much code at all
and most of them worked the first time even with hand-prepared
versions of the expected output.
The previous generate_message function is what's needed when testing
"notmuch new". But after that, we never want to generate a message
without also adding it to the index. So create a new add_message
function with this convenience.
If we had external users of this filter then they might expect some of
these macros to exist. But since this is just internal, that's just
unneeded noise.
With modern MIME attachments, we're already avoiding indexing the
attachments. But for old-school uuencoded data in the mail, we have
been directly indexing the encoded data as terms, (which is not useful
at all---nobody will ever ytry to search based on the seemingly random
uuencoded data).
Additionally, indexing a modestly large uuencoded file seems to make
Xapian go insane, (consuming *lots* of memory).
We fix both problems by detecting uuencoded content and not performing
any indexing of it.
This function detects whether the address in the Reply-To header
already appears in either To or Cc. So give it a name that reflects
what it does (reply_to_header_is_redundant) rather than the old name
which described one possible use of the function, (as a simple
heuristic for detecting whether a mailing list had applied reply-to
munging).
Apparently, GMime doesn't want to create a valid address list object
for an empty string. That's annoying, but it's easy enough to test for
the empty string and avoid the problem.
This change was already recommended in a comment in the original
implementation of this patch. If someone really wants to support
un-munging in the case of To: and Reply-To: having the same address
but different case, then they can provide a portable approach for
that.
This is a test for the recently added feature where we detect that the
reply-to address already exists in the To: or Cc: header so will
already be replied to. In this case we want to include the From:
address in our reply, (where, otherwise we would use the Reply-To
address *instead* of the address in the From header).
Some mailing lists engage in the evil practice of changing the Reply-To
header so that replies from all mailers go to the list by default, at
the expense of not responding to the person who actually sent the
message. When this is detected, we reply to `From' and remove the
duplicate response to the mailing list. Consider a reply to the
following message.
From: Some User <some.user@example.com>
To: Sample users list <sample-users@sample.org>
Reply-To: Sample users list <sample-users@sample.org>
Prior to this patch, `notmuch reply' produces
To: Sample users list <sample-users@sample.org>,
Sample users list <sample-users@sample.org>
and after the patch,
To: Some User <some.user@example.com>,
Sample users list <sample-users@sample.org>
Signed-off-by: Jed Brown <jed@59A2.org>
This code was already duplicated. We move it to a new, shared
add_recipients_from_message function, in preparation for more
sophisticated mailing list logic.
Signed-off-by: Jed Brown <jed@59A2.org>
The feature tested here is that we reply to both the sender and to
others addresses on the To: line of the original message, but that we
don't reply to our own address.
This is the standard support of reply-to, (replying to that address
rather than the from address). It has nothing to do with the proposed
feature for extra-clever handling of a mail from a mailing-list that
has munged the reply-to header.
When reply to a message addresses to an address configured in the
other_email setting in the configuration file, the reply should use
that address in the From header. Test this.
We were sleeping merely to ensure that our updates to the mail store
would result in the mtime of the appropriate directories being
updated. We make the test suite run faster by not sleeping, but
instead explicitly updating the mtime of the directory to a future
time with touch.
We're careful to ensure that the time is not merely in the future
compared to the current time, but also later than any previous update
to the same directory mtime.
This makes the test suite bash-specific, but that's not much of
an issue for me, (if somebody else would prefer some other language
then they can rewrite the test suite and maintain it).
The advantage here is that we'll now be able to easily generate
custom messages for testing operations that depend on the message
content, (such as "notmuch reply", etc.).
This notmuch-test script simply runs a few different notmuch operations,
(things that I found were useful while testing the rename-support code).
It's not useful as a test suite yet, since it doesn't actually check
the results of any operation, (the user of the suite has to know what
the results should be and must manually verify them. So there's no
integration with the build system yet, (no "make test" target).
But I didn't want to lose what I had so far, so here it is.
Add an install target that uses desktop-file-install to install the
desktop file in the appropriate location. The location of the install
can be modified by changing the desktop_dir variable.
Signed-off-by: Jeffrey C. Ollie <jeff@ocjtech.us>
As Keith pointed out, (with a humorous citation from Mark Twain),
the two uses of "very" added nothing to the description. Also,
"large collection of email" was repeated uselessly.
Such as reiserfs or xfs. This has been broken since the merge of
support for rename and deletion of files from the mail store.
Here's the original justification for the patch:
A review of notmuch-new.c shows three uses of ->d_type:
Near line 153, in _entries_resemble_maildir() we can simply allow for
DT_UNKNOWN. This would fail if people have MH-style folders which have
three folders called "new" "cur" and "tmp", but that seems unlikely, in
which case the "tmp" folder would simply not be scanned.
Near line 273 in add_files_recursive() we have another check. If
DT_UNKNOWN, we fall through, then add_files_recursive() does a stat
almost immediately, returning with success if the path isn't a
directory.
Thus, the fallback is already written.
Finally, near line 343, in add_files_recursive() (a long function) we
have another check. Here we can simply treat DT_UNKNOWN as DT_LNK, since
the logic for the stat() results are the same.
